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

Story-Punkte messen den relativen Aufwand eines Arbeitspakets (dessen 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 jenes“), anstatt die Dauer zu schätzen. Genau diese eine Umstellung sorgt dafür, dass die Schätzung auch im Praxisalltag Bestand hat.

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, der der leitende Ingenieur Glauben schenkt, und derjenigen, die der Nachwuchsingenieur 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 fertiggestellt haben?“. Story-Punkte stützen sich auf Letzteres.

Mithilfe der relativen Einstufung kann sich das Team darauf einigen, dass ein Element größer ist als ein anderes, ohne dass sich jemand auf eine bestimmte Stundenzahl festlegen muss. Dadurch werden die Verankerungseffekte 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 Versprechen zu betrachten; bei der Angabe in Punkten bleibt die Schätzung eine Prognose.
• Verschiedene Personen benötigen für dieselbe Aufgabe 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 bei der Punktevergabe berücksichtigt.

So funktioniert die Schätzung von Story-Punkten

Die meisten Teams stimmen in einer Runde Planning Poker auf einer Fibonacci-Skala ab: 1, 2, 3, 5, 8, 13. Die Abstände werden bewusst vergrößert: Je umfangreicher die Arbeit, desto weniger weiß man tatsächlich darüber; daher gibt die Skala nicht mehr vor, dass man eine 9 von einer 10 unterscheiden könnte. Addiert man die Punkte, die ein Team in jedem Sprint erreicht, erhält man die Velocity, also genau den Prognosewert, den die 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, und zwar in Teile, die das Team verstehen und innerhalb eines einzigen Sprints abschließen kann.

Für einen schnelleren, groben ersten Durchgang stufen manche Teams den gesamten Backlog in T-Shirt-Größen ein und wandeln erst die kurzfristig anstehenden Aufgaben in Punkte um, sobald diese verfeinert wurden.

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 Argumentation, und diese Diskussion, die die Annahmen und die verborgene Komplexität hinter der Zahl zutage fördert, ist in der Regel wertvoller als die Zahl selbst. Die vollständige Anleitung zum Planning Poker behandelt die Spielregeln.

Die mit Abstand häufigste Fehlerquelle ist das Team, das damit beginnt, Punkte wieder in Stunden umzurechnen. Sobald diese Umrechnungstabelle im Wiki veröffentlicht wird, verkommt jede Diskussion über die Schätzung zu einem Streit ü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 ist ein Story-Eintrag. Er verfügt über Akzeptanzkriterien („Das Formular akzeptiert keine negativen Mengen mehr“), einen definierten Umfang und eine angemessene Größe; stimmen Sie daher wie bei jedem anderen Story-Eintrag 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 dies immer wieder, und wir können den Fehler nicht reproduzieren. Da die Ursache unbekannt ist, lässt sich der Aufwand für die Behebung nicht abschätzen; eine Story-Point-Abstimmung misst daher lediglich, 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 versandfertig ist. Dies umfasst alle Qualitätssicherungsmaßnahmen, die das Team im Rahmen der Fertigstellung durchführt: automatisierte Tests, manuelle Überprüfung, Barrierefreiheitsprüfungen sowie Sicherheitsüberprüfungen. Die Story gilt nicht als fertiggestellt, sobald der Pull-Request zusammengeführt wurde; sie gilt erst dann als fertiggestellt, 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 reduziert.

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 hat sich die Referenzstory verschoben: Das Team ist schneller geworden, und die ursprüngliche „1“ ist nun kleiner als alles, was es derzeit 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 Button-Text aktualisieren“ ist keine Story, sondern ein Akzeptanzkriterium einer größeren Story. Und manchmal ist die Arbeit tatsächlich geringfügig (eine Wartungsmaßnahme, 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 des Arbeitsaufwands ist einer der häufigsten Punkte, die ein Team in seiner Sprint-Retrospektive überprüft. Wenn Aufgaben regelmäßig unter- oder überschätzt werden, wenn die Velocity stark schwankt oder wenn bereits als „erledigt“ markierte Arbeit immer wieder neu aufgerollt wird, ist die Retrospektive der Ort, an dem das Team sein gemeinsames Gespür für den Arbeitsaufwand 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 im agilen Entwicklungsansatz?

Story-Punkte sind eine Einheit zur relativen Einschätzung: Eine Zahl, die erfasst, wie umfangreich ein Arbeitsteil ist (Aufwand, Komplexität und Unsicherheit zusammen), verglichen mit einer Referenz-Story, die das Team bereits umgesetzt hat. Sie dienen bewusst nicht als Zeitmaß. Das Team vergleicht die einzelnen Elemente untereinander und nicht mit der Uhr.

Warum sollten Story-Punkte anstelle von Stunden verwendet werden?

Menschen können absolute Zeitangaben 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 Stundenschä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; bei stark abweichenden Schätzungen erläutern die Teilnehmer 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 eine Story wie jede andere, und deren 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 Sie die Ursache kennen.

Sind Tests in den Story-Punkten enthalten?

Ja. Punkte erfassen alle Arbeitsschritte zwischen dem Zeitpunkt, zu dem eine Funktion in den Sprint aufgenommen wird, und dem Zeitpunkt, zu dem sie auslieferungsreif 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 Punkte umrechnet, kommt es jedes Mal zu Sprintüberschreitungen, da die Qualitätssicherung den Engpass darstellt, den niemand einkalkuliert hat.

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

Ein paar davon sind in Ordnung. Wenn jedoch der Großteil des Rückstands aus „1ern“ 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 lieber anhand einer aktuellen Referenzstory neu an, anstatt sie zu verkleinern.

Können Sie die Story-Punkte verschiedener Teams miteinander vergleichen?

Nein. Ein Story-Point wird anhand des teaminternen Verständnisses der relativen Größe kalibriert, sodass die 5 eines Teams nicht mit der 5 eines anderen Teams gleichzusetzen ist. Der Vergleich von Velocity oder Punktzahlen zwischen verschiedenen Teams ist sinnlos und, wenn er als Ziel verwendet wird, sogar schädlich: Er veranlasst Teams dazu, ihre Schätzungen zu übertreiben. Story-Punkte sind ein Planungsinstrument für die eigene Prognose eines einzelnen Teams und 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 verzerren.
• Agile Schätzverfahren: Wann welche Methode zum Einsatz kommen sollte und inwiefern die einzelnen Methoden ihre Grenzen haben.
• 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.