Montag, 6. Juli 2020

Was passiert mit den Story Points von nicht-fertigen Product Backlog Items?

Ein Thema aus der Scrum-Praxis: Vor kurzem hatten wir eine Diskussion über das Anrechnen von Story Points. Wenn ein Scrum Team mit bestimmten Product Backlog Items nicht fertig wird, kommen diese Items zurück ins Product Backlog. Dabei wird der Restaufwand und nicht der volle Aufwand vermerkt. Wenn das Team diese Items abschließt, wird auch nur der Restaufwand angerechnet. Die Differenz zum ursprünglich geschätzten Aufwand verfällt. Eigentlich klar. Aber können Sie auch erklären, warum das so ist?

Schätzen ist für die Planung wichtig

Wenn wir bei der Produktentwicklung das Geld unserer Finanzierer verbrennen, haben diese auch ein Anrecht auf Informationen: Wie lange wird es noch dauern? Wie sieht Eure Planung aus?

Nun mag man über die Zuverlässigkeit oder die Aussagekraft bestimmter Schätzmethoden diskutieren. Nicht schätzen ist aber keine Alternative. Auf keinen Fall sollten nur auf Basis von Zeit schätzen (siehe Stichwort Planungsfehlschluss in der Wikipedia).

Wir brauchen ein Maß für Arbeit, bevor wir auf die Zeit schätzen. Wenn wir kein besseres Maß für Arbeit haben, können wir uns mit den sog. Story Points behelfen. Mit Story Points setzen wir die verschiedenen Product Backlog Items in Beziehung zueinander.

Im folgenden Beispiel will ein Scrum Team zehn Items mit ingesamt 136 Story Points umsetzen.

Das Team wird nicht fertig

Sehen wir uns die Abarbeitung in den ersten vier Sprints an.

In Sprint 1 wird Product Backlog Item 1 fertig. In Sprint 2 nimmt sich das Team PBI 2 vor, wird aber nicht fertig. Der Item geht mit Restaufwand 8 in den nächsten Sprint und wird dort auch abgeschlossen. Zusätzlich hat sich das Team auch PBI 3 vorgenommen. PBI 3 wird nicht fertig und geht mit Restaufwand 13 in Sprint 4 und wird dann auch abgeschlossen.

Im Mittel hat das Entwicklungsteam als 8,5 Story Points pro Sprint geschafft ((13+0+8+13)/4).

Aber ist das nicht falsch? Hätten wir nicht die vollen 55 Punkte anrechnen müssen? Das war doch die ursprüngliche Schätzung?

Schätzen ist VOR ALLEM für die Planung wichtig

In diesem Fall hätten wir eine mittlere Abarbeitungsgeschwindigkeit von 13,75 Story Points (55/4) erreicht, also einen Wert der um über 60% schneller ist.

Nach der ersten Betrachtung oben braucht das Team 16 Sprints, um die ursprünglichen 136 Story Points abzuarbeiten. Nach der zweiten Betrachtung wäre das Team schon nach 10 Sprints, also 6 Sprints früher fertig.

Damit entsteht eine falsche Erwartung bei den Stakeholdern.

Was vielleicht übersehen wird: Der restliche Gesamtaufwand des Backlogs sinkt ja auch. Erfahrungen aus dem Sprint Review fließen zurück ins Product Backlog, d. h. statt der ursprünglichen Schätzung stehen bei bestimmten Backlog Items nur noch die Restaufwände.

Jetzt können Sie besser erklären, warum wir mit Restaufwänden arbeiten.


1 Kommentar:

  1. Ich arbeite bei Story Points grundsätzlich nicht mit Restaufwänden. Wenn eine Story im Sprint nicht fertig wird, landet sie mit seiner kompletten Size im nächsten Sprint. Ich frage dann eher das Team, was sie noch denken, was im Rahmen einer "Überkipper"-Story noch zu tun ist. In den meisten Fällen committet sich das Team für den kommenden Sprint auf Stories, die in der Summe über der Velocity liegen, weil eben die "Restaufwände" im überseh- und beherrschbaren Rahmen liegen. Über mehrere Iterationen hinweg normalisiert gleichen sich die Sprints bzgl. der Velocity wieder aus. Aber ich glaube wir sind uns einig, dass Überkipper die Ausnahme sein sollten und das Team eher bemüht sein sollte, die Ursachen dafür auszuräumen.

    AntwortenLöschen