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

Story-Points dienen dazu, den relativen Aufwand, die Komplexität und die Unsicherheit einer Aufgabe zu messen – nicht die Arbeitsstunden. Wie man den Umfang anhand einer Referenz-Story einschätzt und welche Fragen Teams dabei vor Probleme stellen.

Story-Punkte messen den relativen Aufwand einer Aufgabe – deren Umfang, Komplexität und Unsicherheit, zusammengefasst in einer einzigen Zahl – und nicht die dafür benötigte Arbeitszeit. Sie bewerten ein Backlog-Element anhand einer Referenz-Story, die das Team bereits fertiggestellt hat („das ist etwa doppelt so groß wie diese“), anstatt die Dauer zu schätzen. Genau diese eine Änderung 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, 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.

Relative Größenbestimmung ermöglicht es dem Team, sich darauf zu einigen, dass ein Element größer ist als ein anderes, ohne dass sich jemand auf eine bestimmte Stundenzahl festlegen muss – wodurch der Verankerungseffekt und die durch Dienstalter bedingte Voreingenommenheit, die mit Stundenschätzungen einhergehen, umgangen werden. Die sich daraus ergebende Zahl stellt keine Dauer dar, sondern eine Position auf einer gemeinsamen Skala.

Die Skala und wozu die Punkte dienen

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 – genau das Ergebnis, das die Prognosepunkte eigentlich liefern sollen.

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 Verfeinerungstreffen 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?“ 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 eine Story. Sie verfügt über Akzeptanzkriterien („Das Formular akzeptiert keine negativen Mengen mehr“), einen definierten Umfang und eine angemessene Größe – stimmen Sie also 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.

Eine Ausnahme bildet der Fehler, bei dem die Ursache noch unklar ist – die Datenkorruption untersuchen, herausfinden, warum sich p99 verdoppelt hat, Kunden melden das Problem immer wieder, wir können es jedoch 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 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 – was alle Qualitätssicherungsmaßnahmen umfasst, die das Team als Teil des „Fertig“-Zustands 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 eine Ein-Punkt-Geschichte wollen

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 verbucht, geht dieser Abstufungsgrad verloren – alles Geringfügige wird als 1 gewertet, alles Größere als 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. Vielmehr muss man sich fragen, 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“. 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.

Häufig gestellte Fragen

Was sind Story-Punkte in der agilen Entwicklung?

Story-Punkte sind eine Einheit zur relativen Einschätzung: Eine Zahl, die den Umfang eines Arbeitspakets – also dessen Aufwand, Komplexität und Unsicherheit in ihrer Gesamtheit – im Vergleich zu einer Referenz-Story erfasst, die das Team bereits umgesetzt hat. Sie sind bewusst kein Maß für den Zeitaufwand. Das Team bewertet jedes Arbeitspaket im Vergleich zu den anderen und nicht anhand der benötigten Zeit.

Sollten Fehler mit Story-Punkten bewertet werden?

Ja, wenn die Ursache eines Fehlers bekannt ist und es eine klare Lösung gibt, handelt es sich um einen Fall wie jeden anderen auch, 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 Sie die Ursache kennen.

Sind Tests in den Story-Punkten enthalten?

Ja. Punkte erfassen alle Schritte 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 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 – alles wird als „winzig“ oder „größer“ eingestuft. Passen Sie die Skala lieber anhand einer aktuellen Referenzstory neu an, anstatt sie zu verkleinern.

Weiterführende Literatur