Was sind „verbrauchte Story Points“ in Trello?

Verbrauchte Story Points: Ein agiles Anti-Pattern

"Verbrauchte Punkte" sind eine Art Burn-Down-Metrik, die einige Praktiker verwenden, um den Fortschritt einer Geschichte im Vergleich zu ihren ursprünglichen Schätzungen zu verfolgen. Es soll den Prozentsatz der abgeschlossenen Arbeit anzeigen, Überschreitungen abschätzen oder den Bedarf an kollaborativer Kommunikation über den Story-Status reduzieren.

In meiner Coaching-Praxis wird die Verwendung von verbrauchten Punkten als Scrum/Kanban-Anti-Pattern angesehen. Story-Point-Schätzungen sind außerhalb des Schätzungsprozesses selbst ungültig und haben außerhalb der Sprint-Planung oder Release-Planung keinen Nutzen. Sie sollten als flüchtige Werte behandelt werden und sollten:

1. Während der Sprintplanung erstellt, überprüft oder überarbeitet.
2. Wird während der Sprint-Retrospektiven besprochen, um den Schätzungs- und Planungsprozess des Teams zu verfeinern.
3. Wird zusammen mit dem Zeitfeld verworfen, außer als aggregierte Summe zur Verwendung in der Geschwindigkeitsmetrik.

Sehen wir uns ein konkretes Beispiel an und diskutieren wir, warum Menschen verbrauchte Punkte verwenden und was sie stattdessen tun sollten.

Ein ausgearbeitetes Beispiel

Angenommen, Sie verwenden Trello mit dem beliebten Scrum für Trello Chrome-Plugin. Sie könnten ein Board wie dieses haben:

Schätzung des abgeschlossenen Prozentsatzes

In der Spalte Work in Progress wird die Story auf fünf Story Points geschätzt, und das Team hat geschätzt, dass 50 % der prognostizierten Arbeit abgeschlossen sind. Theoretisch bedeutet das, dass die Geschichte in der zweiten Spalte halb fertig ist.

Aber warte! In Scrum, wie in den meisten erfolgreichen agilen Frameworks, ist jede Geschichte entweder fertig oder nicht fertig . Das gesamte Framework ist darauf ausgelegt, von falscher Genauigkeit und sinnlosen Statusberichten wegzukommen, in denen behauptet wird, dass 60 % von etwas zu 80 % erledigt sind. In Scrum ist eine Story am Ende des Sprints entweder zu 100 % fertig (natürlich gemäß der Definition of Done!) oder sie ist einfach unvollständig und muss unvollendet an das Product Backlog zurückgegeben werden, wo sie umgeschrieben und neu priorisiert werden kann , verschoben und neu geplant.

Also, warum verwendet jemand verbrauchte Punkte? Die Leute, die es tun, haben oft Gründe, und diese Gründe fallen im Allgemeinen in ein paar gängige Kategorien.

1. Ihr Prozess ist nicht vollständig kooperativ, daher sind "verbrauchte Punkte" eine Möglichkeit, aussagekräftigere Statusaktualisierungen zu vermeiden. Leider ist „Ich bin zu 50 % fertig“ nicht besonders hilfreich, aber „Ich arbeite an einer Story, die ich nicht fertigstellen kann, wenn Alice nicht mit ihrer Story fertig ist, um das Widget zu integrieren“ wäre klar und umsetzbar.
2. Der Scrum Master, Product Owner oder ein externer Stakeholder versucht, Burn-Down-Diagramme, tägliche Standups oder andere Zeremonien und Artefakte durch Metriken auf einer Karte zu ersetzen. Story Points sind ein Planungstool, keine Leistungsmetrik, daher ist ihre Verwendung für irgendetwas anderes ein Missbrauch der Metrik, der unzuverlässige Informationen liefert.
3. Das Team und seine Stakeholder verstehen Schätzungen oder Prognosen nicht vollständig und versuchen, die Schätzungen des Aufwands an die Arbeitsstunden zu binden. Ihre zugrunde liegende Annahme ist, dass Story Points intrinsische Konversionsraten zu Zeit haben und dass jede Story einen streng linearen Verlauf vom Anfang bis zum Ende hat . Beides ist nicht der Fall.

Bei richtiger Ausführung wird ein Sprint Backlog in erledigte oder nicht erledigte Elemente zerlegt, die im Sprint Burn-Down gemessen werden können. Dies ist eine viel genauere Ansicht, wie viel Arbeit im aktuellen Sprint verbleibt. Im Gegensatz dazu ist der Prozentsatz der abgeschlossenen Geschichten eine weitere subjektive Proxy-Metrik und fungiert als ungenaue Sekundärprognose. Wenn Sie zum Beispiel sagen:

Die Work-in-Progress-Geschichte ist zu 50 % fertig, also schätze ich, dass ich weitere 5 Tage brauchen werde, um sie fertigzustellen.

Alles, was Sie erreicht haben, ist das Hinzufügen einer neuen zeitbasierten (und weitgehend unbegründeten) Prognose über die ursprüngliche Aufwandsprognose hinaus. Die Erfahrung zeigt, dass dies selten genau ist und die Zeit zum Nachverfolgen fast nie wert ist. „Done“ oder „not-done“ sind die Münzen des Reiches in agilen Frameworks!

Verfolgung von Überschreitungen und ungenauen Schätzungen

Der andere Anwendungsfall wird durch die dritte Karte veranschaulicht, die sich in der Spalte „Fertig“ befindet. Auf dieser Karte können Sie sehen, dass das Team die Story auf drei Story Points geschätzt hat, aber später behauptet, dass es acht Story Points gedauert hat, um sie abzuschließen.

Während es nichts Falsches daran gibt, in einer Sprint-Retrospektive darauf hinzuweisen, dass eine User Story grob unterschätzt wurde, und die Erfahrung zu nutzen, um den Schätzungs- und Planungsprozess des Teams beim nächsten Mal zu verbessern, ist der Nutzen einer formalen Verfolgung des Ausmaßes der Fehleinschätzung gleich null .

In einer Retrospektive ist es vollkommen vernünftig, etwas zu sagen wie:

Wir alle dachten, dass diese Geschichte eine 3 ist, weil ... aber es stellt sich heraus, dass wir die Abhängigkeiten von foo , bar und baz nicht durchdacht haben . Außerdem mussten wir das Zeug verkleinern, um die Geschichte zu vervollständigen, und wir dachten nicht daran, dafür ein Sprint-Backlog-Element zu erstellen oder es in unsere Schätzungen aufzunehmen. Vielleicht müssen wir solche Geschichten beim Sprint Planning besser zerlegen.

Ein Sprint ist jedoch eine kurzlebige Zeitbox. Sobald der Sprint vorbei ist, ist er für immer weg. Entweder wurde das Sprintziel erreicht oder nicht. Entweder wurde eine Story in diesem Sprint abgeschlossen oder nicht. Spielt es sechs Monate später eine Rolle, ob eine bestimmte Geschichte leichter oder schwerer zu vervollständigen war als ursprünglich geplant? Natürlich nicht.

Die wahren Gründe, warum Menschen diese Post-hoc-Metrik verwenden, sind:

1. Das Team wird von der Organisation „zur Rechenschaft gezogen“, um zu zeigen, wie viel Mühe es investiert. Dies ist besonders häufig, wenn Sprintziele nicht erreicht werden und das Team sagen möchte: „Wir haben nicht alle erforderlichen Storys abgeschlossen um das Sprintziel zu erreichen, aber sehen Sie sich an, wie viel Aufwand wir in Story X stecken!"
2. Das Team behandelt die Geschwindigkeit fälschlicherweise als Maß für die Produktivität und nicht als Maß für die historische Teamkapazität und versucht, die Metrik zu spielen, um die Optik zu verbessern. „Wir haben diese Geschichte auf 3 Punkte geschätzt, aber es hat wirklich 8 gedauert, also haben wir in diesem Sprint wirklich 25 Story-Punkte statt 20 gemacht! Wir sind Super-Performer; bitte feuern Sie uns nicht!“
3. Das obere Management behandelt Geschwindigkeit fälschlicherweise als Leistungsziel und nicht als Prognoseinstrument und treibt das Team dazu, mehr Arbeit zu übernehmen, als nachhaltig sein könnte. Die ursprüngliche Schätzung wurde möglicherweise eher von der Führung als vom Team festgelegt, oder die Story wurde von Stakeholdern ohne ausreichende Dekomposition in den Sprint geschoben. Möchten Sie wirklich separate Geschwindigkeitsmetriken verfolgen, um ein tieferes Prozessproblem zu vertuschen?

Überprüfen, nicht verfolgen

Es gibt mehrere Denkrichtungen darüber, ob Teams jemals Story Points innerhalb eines Sprints anpassen sollten. Dies ist ein komplexes Thema, das außerhalb des Rahmens dieser Antwort liegt, aber die zu vereinfachte Antwort lautet, dass Sie im Allgemeinen besser dran sind, Ihre anfänglichen Schätzungen beizubehalten, wenn Ihr Ziel darin besteht, Ihren Prozess zu verbessern. Es ist viel besser (aus Sicht des Prozesses), zu sagen: „Hey, wir haben uns verschätzt! anstatt den Käse ständig zu bewegen.

Die Geschwindigkeit ist eine Metrik, die im Laufe der Zeit gegen einen Mittelwert konvergiert. Solange Sie den Schätzungsprozess weiter verbessern, wird sich die Genauigkeit Ihrer Geschwindigkeit als Prädiktor für die Sprintkapazität verbessern. Der Wert der Geschwindigkeit liegt in ihrer Fähigkeit, die Kapazität trotz Störungen und Periodizität vorherzusagen, daher gibt es fast nie einen guten Grund, die Ergebnisse eines einzelnen Sprints neu zu berechnen – und tatsächlich zahlreiche Gründe , dies nicht zu tun!

Agile Teams sollten klein genug und Scrum-Sprints kurz genug sein, dass eine formelle Nachverfolgung von Abweichungen von der Planungsschätzung nicht erforderlich sein sollte. Da diese Daten niemals außerhalb einer einzelnen Sprint-Timebox verwendet werden sollten, ist es auch unnötig, diese Daten über die Timebox hinaus aufzubewahren.

Zusammenfassend lässt sich sagen, dass es sich lohnt, Diskrepanzen in Schätzungen zu überprüfen oder Prozesshindernisse zu identifizieren, die verhindert haben, dass eine Geschichte zu 100 % fertig ist. Das Nachverfolgen dieser Daten als erstklassiges Element auf einer Story-Karte ist jedoch ein Anti-Pattern.