Was sind Story-Punkte? Schätzung des Aufwands, nicht der Zeit

Story-Punkte messen den relativen Aufwand einer Aufgabe (deren Umfang, Komplexität und Unsicherheit in einer einzigen Zahl zusammengefasst), nicht die dafür benötigten Stunden. Sie bewerten ein Backlog-Element anhand einer Referenz-Story, die das Team bereits fertiggestellt hat („das hier ist etwa doppelt so groß wie jene“), anstatt die Dauer zu schätzen. Genau diese eine Umstellung sorgt dafür, dass die Schätzung dem Vergleich mit der Realität standhält.

Warum sollte man den Aufwand messen und nicht die Zeit?

Ein Team, das in Stunden schätzt, arbeitet im Grunde mit zwei Schätzungen: derjenigen, an die der leitende Ingenieur glaubt, und derjenigen, die der junge Ingenieur nach Aufrundung notiert, um verantwortungsbewusst zu wirken. Menschen sind unzuverlässig bei der Frage „Wie lange wird das dauern?“, aber überraschend gut bei der Frage „Ist das umfangreicher als das, was wir im letzten Sprint abgeschlossen haben?“. Story-Punkte stützen sich auf Letzteres.

Mithilfe der relativen Einstufung kann sich das Team darauf einigen, dass ein Element umfangreicher ist als ein anderes, ohne dass sich jemand auf eine bestimmte Stundenzahl festlegen muss. Dadurch werden der Verankerungseffekt und die durch Dienstalter bedingte Voreingenommenheit umgangen, die bei Stundenschätzungen häufig auftreten. Die sich daraus ergebende Zahl stellt keine Dauer dar, sondern eine Position auf einer gemeinsamen Skala.

Die Bemessung anhand des Aufwands anstelle von Stunden umgeht drei Probleme, die stundenbasierte Schätzungen mit sich bringen:

• Eine Schätzung ist keine verbindliche Zusage. Bei der Angabe in Stunden neigen die Beteiligten dazu, „8 Stunden“ als festes Versprechen zu betrachten; bei der Angabe in Punkten bleibt die Schätzung eine Prognose.
• Für dieselbe Aufgabe benötigen verschiedene Personen unterschiedlich viel Zeit. Ein Punkt spiegelt die Arbeit wider, nicht die Person.
• Die Dauer berücksichtigt das Risiko nicht. Eine kurze, aber ungewisse Aufgabe kann riskanter sein als eine lange, gut durchschaute Aufgabe; daher wird diese Ungewissheit in die Punktwertung einbezogen.

So funktioniert die Schätzung von Story-Punkten

Die meisten Teams stimmen in einer Runde Planning Poker anhand einer Fibonacci-Skala ab: 1, 2, 3, 5, 8, 13. Die Abstände werden bewusst größer: Je umfangreicher die Arbeit, desto weniger weiß man tatsächlich darüber, sodass die Skala nicht mehr vorgibt, man könne eine 9 von einer 10 unterscheiden. Addiert man die Punkte, die ein Team in jedem Sprint erreicht, erhält man die Velocity, also genau das Ergebnis, das die Prognose-Eingabepunkte eigentlich liefern sollen.

Wenn ein Element größer als etwa 13 ausfällt, ist dies in der Regel ein Hinweis darauf, dass Sie es aufteilen sollten – in Teile, die das Team verstehen und innerhalb eines einzigen Sprints abschließen kann.

Für einen schnelleren, groben ersten Durchgang stufen einige Teams das gesamte Backlog in T-Shirt-Größen ein und wandeln erst nach der Verfeinerung nur die kurzfristig anstehenden Aufgaben in Punkte um. Das gesamte Backlog auf einmal einstufen? Beginnen Sie mit einer Affinitätsschätzung und weisen Sie den Gruppen am Ende Punkte zu.

In einer Runde Planning Poker decken alle Teilnehmer ihre Karten gleichzeitig auf, sodass sich niemand von der lautesten oder ranghöchsten Stimme beeinflussen lässt. Wenn die höchsten und niedrigsten Schätzungen voneinander abweichen, erläutern die beiden betreffenden Personen ihre Gründe, und diese Diskussion, die die Annahmen und die verborgene Komplexität hinter der Zahl ans Licht bringt, ist in der Regel wertvoller als die Zahl selbst. Die vollständige Anleitung zum Planning Poker behandelt die Spielmechanik.

Die mit Abstand häufigste Fehlerquelle ist das Team, das damit beginnt, Punkte wieder in Stunden umzurechnen. Sobald diese Umrechnungstabelle im Wiki erscheint, verkommt jede Schätzungsdiskussion zu einer Debatte über die Dauer, und der Aspekt des relativen Aufwands geht verloren.

Auf welches Werk sollten Sie hinweisen?

Bei jedem Verfeinerungstreffen stellen sich zwei Fragen: Bringt dies überhaupt Punkte ein, und wenn ja, wie viele? Für die Frage „Wie viele?“ dient die Skala. Für die Frage „Bringt es Punkte ein?“ gibt es eine Faustregel: Vergeben Sie Punkte für alles, was das Team im Rahmen seiner zugesagten Arbeit ausliefert, damit das Velocity-Signal widerspiegelt, wohin die Kapazität tatsächlich fließt.

Fehler

Ein Fehler mit bekannter Ursache und einer eindeutigen Behebung stellt eine Story dar. Sie verfügt über Akzeptanzkriterien („Das Formular akzeptiert keine negativen Mengen mehr“), einen definierten Umfang und eine angemessene Größe; stimmen Sie daher wie bei jeder anderen Story darüber ab. Die Bearbeitung von Fehlern und die Entwicklung neuer Funktionen konkurrieren um dieselbe Kapazität, und dies sollte sich in der Velocity widerspiegeln.

Die Ausnahme bildet der Fehler, bei dem die Ursache noch unbekannt ist: Untersuchen Sie die Datenbeschädigung, finden Sie heraus, warum sich p99 verdoppelt hat, Kunden melden den Fehler immer wieder, wir können ihn jedoch nicht reproduzieren. Da die Ursache unbekannt ist, lässt sich der Umfang der Behebung nicht beziffern; eine Abstimmung über Story-Points gibt daher lediglich wieder, was das Team zu finden hofft. Nehmen Sie diese Fälle in einen zeitlich begrenzten Untersuchungsplan auf: Verbringen Sie ein oder zwei Tage mit der Suche und legen Sie anschließend eine konkrete Story vor, die Ihre Ergebnisse widerspiegelt.

Test und Qualitätssicherung

Story-Points dienen zur Einstufung des Arbeitsaufwands zwischen dem Zeitpunkt, zu dem eine Story in den Sprint aufgenommen wird, und dem Zeitpunkt, zu dem sie auslieferungsbereit ist. Dies umfasst alle Qualitätssicherungsmaßnahmen, die das Team als Teil der Fertigstellung durchführt: automatisierte Tests, manuelle Überprüfung, Barrierefreiheitsprüfungen sowie Sicherheitsüberprüfungen. Die Story gilt nicht als abgeschlossen, wenn der Pull-Request zusammengeführt wird; sie gilt erst dann als abgeschlossen, wenn sie die Definition von „fertig“ erfüllt.

Teams, die sich ausschließlich auf die Entwicklung konzentrieren und die Qualitätssicherung separat hinzufügen, übernehmen sich in jedem Sprint, da die Qualitätssicherung den Engpass darstellt, den niemand einkalkuliert hat. Wenn ein separates QA-Team für die Tests verantwortlich ist, fallen für die Story dennoch die entwicklungsseitigen Kosten für die Zusammenarbeit mit diesem Team an: die Vorbereitung des Builds, das Erstellen des Testplans und die Beantwortung von Fragen. Dieser Teil ist nicht kostenlos und fließt daher in die Schätzung ein.

Warum Sie nur selten eine Ein-Punkt-Geschichte wünschen

Punkte sind relativ, daher ist eine 1 nur im Zusammenhang mit einer 2, einer 3 oder einer 8 aussagekräftig. Wenn ein Team ständig „1-Punkte-Geschichten“ vorzuweisen hat, geht dieser Gradient verloren: Alles Unbedeutende ist eine 1, alles Größere ist eine 2 oder 3, und die Skala ist auf einen Münzwurf geschrumpft.

Die Lösung besteht nicht darin, „1er“ zu verbieten (das ist die Cargo-Kult-Version der Regel). Die Lösung besteht darin, zu hinterfragen, warum so viel Arbeit am unteren Ende der Skala angesiedelt ist. In der Regel ist die Referenzstory verschoben worden: Das Team ist schneller geworden, und die ursprüngliche „1“ ist nun kleiner als alles, was es ausliefert; wählen Sie daher eine neuere Referenz, an die sich das Team erinnert, und legen Sie einen neuen Ankerpunkt fest. Manchmal zerlegt das Team bei der Verfeinerung die Aufgaben zu stark und macht aus jedem Akzeptanzkriterium eine eigene Story: „Den Text der Schaltfläche aktualisieren“ ist keine Story, sondern ein Akzeptanzkriterium einer größeren Story. Und manchmal ist der Arbeitsaufwand tatsächlich gering (ein Wartungsquartal, eine Textänderung, die einer rechtlichen Prüfung bedarf, eine Konfigurationsanpassung, die die Produktionsumgebung betrifft); in diesem Fall erfüllen die Punkte ihren Zweck, und es gibt nichts zu korrigieren.

Das Signal, auf das Sie achten sollten, lautet nicht „keine 1er überhaupt“. Es ist vielmehr, dass 1er den Großteil des Rückstands ausmachen. Ein oder zwei pro Sprint sind in Ordnung. Wenn jede zweite Story eine 1 ist, bedeutet dies, dass die Frage nach der Kalibrierung schon zu lange nicht mehr gestellt wurde.

Story-Punkte und die Retrospektive

Die Einschätzung ist einer der häufigsten Punkte, die ein Team in seiner Sprint-Retrospektive überprüft. Wenn Aufgaben regelmäßig zu niedrig oder zu hoch eingeschätzt werden, wenn die Velocity stark schwankt oder wenn bereits als „abgeschlossen“ markierte Arbeit immer wieder neu aufgerollt wird, ist die Retrospektive der Ort, an dem das Team sein gemeinsames Gespür für den Umfang der Arbeit neu kalibriert und die Aufteilung der Arbeit präzisiert. Die Genauigkeit der Schätzungen verbessert sich durch diesen Feedback-Kreislauf und nicht dadurch, dass man sich im Vorfeld noch mehr Mühe gibt.

Häufig gestellte Fragen

Was sind Story-Punkte in der agilen Entwicklung?

Story-Punkte sind eine Einheit zur relativen Einschätzung: eine Zahl, die angibt, wie umfangreich ein Arbeitspaket ist (Aufwand, Komplexität und Unsicherheit zusammengenommen) im Vergleich zu einer Referenz-Story, die das Team bereits umgesetzt hat. Sie sind bewusst kein Maß für den Zeitaufwand. Das Team vergleicht jedes Element mit den anderen und nicht mit der Uhr.

Warum sollten Story-Punkte anstelle von Stunden verwendet werden?

Menschen können absolute Zeiträume nur schlecht einschätzen, sind jedoch gut darin, zu beurteilen, ob eine Sache größer ist als eine andere, und Story-Points stützen sich auf diese Stärke. Sie vermeiden zudem die Falle, eine Schätzung als verbindliche Zusage zu betrachten, berücksichtigen die Tatsache, dass dieselbe Aufgabe bei verschiedenen Personen unterschiedlich viel Zeit in Anspruch nimmt, und beziehen Komplexität und Risiko mit ein – nicht nur die Dauer. Über mehrere Sprints hinweg wird die Velocity eines Teams in Punkten zu einer zuverlässigeren Prognose als die Summe der Stundenabschätzungen.

Wie schätzen Sie Story-Punkte ein?

Die meisten Teams nutzen Planning Poker. Jemand erläutert ein Backlog-Element, das Team diskutiert darüber, und jeder wählt für sich einen Wert aus einer gemeinsamen Skala aus, in der Regel einer Fibonacci-ähnlichen Folge (1, 2, 3, 5, 8, 13). Alle geben ihre Werte gleichzeitig bekannt; wenn die Schätzungen stark voneinander abweichen, erläutern diejenigen mit den höchsten und niedrigsten Werten ihre Überlegungen, und das Team stimmt erneut ab, bis sich die Meinungen annähern. Die Diskussion, durch die verborgene Komplexitäten zutage treten, ist oft wertvoller als die Zahl selbst.

Sollten Fehler mit Story-Punkten bewertet werden?

Ja, wenn die Ursache eines Fehlers bekannt ist und es eine eindeutige Lösung gibt: Dann handelt es sich um ein Feature wie jedes andere, und dessen Erfassung sorgt dafür, dass die Velocity realistisch widerspiegelt, wohin die Kapazitäten fließen. Eine Ausnahme bilden explorative Fehler, deren Umfang Sie noch nicht abschätzen können; ordnen Sie diese einem zeitlich begrenzten Untersuchungsprozess zu und ermitteln Sie den tatsächlichen Aufwand für die Behebung, sobald Ihnen die Ursache bekannt ist.

Sind Tests in den Story-Points enthalten?

Ja. Punkte erfassen alle Arbeitsschritte zwischen dem Zeitpunkt, zu dem eine Story in den Sprint aufgenommen wird, und dem Zeitpunkt, zu dem sie auslieferungsbereit ist; dazu gehören auch die Tests und die Qualitätssicherung, die das Team im Rahmen seiner „Definition of Done“ durchführt. Wenn man nur die Entwicklungsarbeit in Punkten bewertet, kommt es jedes Mal zu Sprintüberschreitungen, da die Qualitätssicherung den Engpass darstellt, den niemand einkalkuliert hat.

Warum sollten Sie „1-Punkt-Berichte“ vermeiden?

Ein paar davon sind in Ordnung. Wenn jedoch der Großteil des Rückstands aus „1en“ besteht, hat sich die Referenzstory des Teams verschoben und die Skala ist zusammengebrochen, sodass alles als „winzig“ oder „größer“ wahrgenommen wird. Passen Sie die Skala anhand einer aktuellen Referenzstory neu an, anstatt sie zu verkleinern.

Können Sie Story-Points zwischen verschiedenen Teams vergleichen?

Nein. Ein Story Point wird auf das eigene Verständnis eines Teams hinsichtlich der relativen Größe abgestimmt, sodass die 5 eines Teams nicht mit der 5 eines anderen Teams gleichzusetzen ist. Der Vergleich von Velocity oder Punkteständen zwischen verschiedenen Teams ist sinnlos und, wenn er als Zielvorgabe verwendet wird, sogar schädlich: Er veranlasst Teams dazu, ihre Schätzungen zu überhöhen. Story-Punkte sind ein Planungsinstrument für die eigene Prognose eines einzelnen Teams, keine Produktivitätskennzahl zum Vergleich.

Weiterführende Literatur

• Warum bei Story-Points die Fibonacci-Folge zum Einsatz kommt: Warum die Abstände mit steigenden Zahlen größer werden.
• Story-Points vs. Stunden: Die Umrechnungsfalle und was zu tun ist, wenn jemand einen Termin benötigt.
• Velocity: Wendepunkte in eine Prognose einbeziehen, ohne sie zu unterbrechen.
• Agile Schätzverfahren: Welche Methode kommt wann zum Einsatz, und wo liegen die jeweiligen Schwachstellen?
• Sprint-Retrospektive: Hier passen Teams ihre Schätzungen an, die immer wieder daneben liegen.
• Leitfaden zur agilen Schätzung: Das gesamte Spektrum – vom Planning Poker bis zur Aufteilung von Stories.
• Kostenloses Planning Poker für agile Teams: Bestimmen Sie gemeinsam in Echtzeit den Umfang Ihres Backlogs.