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 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 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 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 auftreten können. 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 hingegen 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 bei der Punktevergabe berücksichtigt.

Die Skala und wofür die Punkte stehen

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 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 – in Teile, die das Team verstehen und innerhalb eines einzigen Sprints abschließen kann.

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

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öchste und die niedrigste Schätzung voneinander abweichen, erläutern die beiden betreffenden Personen ihre Überlegungen, 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 ein 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 Verfeinerungsmeeting stellen sich zwei Fragen: Bringt dies überhaupt Punkte ein, und wenn ja, wie viele? Für die Frage „Wie viele?“ ist die Skala vorgesehen. Für die Frage „Bringt es Punkte ein?“ gilt 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. 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 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 unklar ist: Untersuchen Sie die Datenkorruption, 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 beziffern; eine Story-Point-Bewertung 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 für das vor, was Sie gefunden haben.

Test und Qualitätssicherung

Story-Points dienen zur Bemessung des Arbeitsaufwands zwischen dem Zeitpunkt, zu dem eine Story in den Sprint aufgenommen wird, und dem Zeitpunkt, zu dem sie bereit zur Auslieferung 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, sobald der Pull-Request zusammengeführt wurde; 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 selten einen Artikel mit nur einem Punkt 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 nur 1-Punkte-Erfolge vorweisen kann, 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 ist die Referenzstory verschoben worden: 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 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 „überhaupt keine 1er“. Vielmehr ist es der Umstand, 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 im Rahmen 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 Aufgaben immer wieder neu aufgerollt werden, dient die Retrospektive dem Team dazu, sein gemeinsames Gespür für den Arbeitsaufwand neu zu kalibrieren und die Aufteilung der Arbeit zu verfeinern. Die Genauigkeit der Schätzungen verbessert sich durch diese Rückkopplungsschleife, 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 bewertet jedes Element im Vergleich zu den anderen und nicht im Vergleich zur Uhrzeit.

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 neben der Dauer auch Komplexität und Risiko mit ein. Ü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; wenn die Schätzungen stark voneinander abweichen, erläutern die Personen 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ät fließt. 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 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 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-Berichte“ 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 Story-Points zwischen verschiedenen Teams 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-Werten oder Punktzahlen zwischen verschiedenen Teams ist sinnlos und, wenn er als Zielvorgabe verwendet wird, sogar schädlich: Er veranlasst Teams dazu, ihre Schätzungen künstlich aufzublähen. 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-Punkten 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.