Burn-Down-Charts und Estimations – brauche ich das?

Das Schätzen von User Stories ist bei vielen Teamsessenzieller Bestandteil jedes Sprints. Oft werden die Schätzungen dazugenutzt, ein langfristiges Burn-Down-Chart zu erstellen und Sprint für Sprintabzutragen, welcher Funktionsumfang geliefert wurde. Doch ist diese Praxiswirklich sinnvoll – schließlich verschlingt das Schätzen sehr viel Zeit?

Die Antwort ist ein klares Ja…

…wenn ihr ein Team seid, das einen grob festgelegten Umfang an Funktionalität zu einem bestimmten Zeitpunkt fertiggestellt haben soll. Wenn ihr zum Beispiel ein MVP Release plant oder eine neue Version einer Software bis Deadline X auf den Markt bringen wollt. In diesem Fall braucht das Management von euch eine möglichst verlässliche Aussage darüber, ob ihr den versprochenen Umfang liefern könnt.

In diesem Fall hat sich das alte Muster bewährt: Schätzt die Funktionalität auf Epic Basis zu Beginn des Zeitraums mittels Magic Estimation oder Planning Poker in Storypoints nach der Fibonacci Sequenz (1,2,3,5,8,13…).Trackt die Storypunkte, die ihr pro Sprint abschließt (eure Velocity), um ein langfristiges Burn-Down-Chart zu erstellen, das euch zeigt, wann ihr im besten/schlechtesten Fall die gewünschte Menge an Funktionalität liefern könnt.

Der Verlauf des Burn-Down-Charts zeigt euch frühzeitig, ob ihr auf einem guten Weg zum Release seid und erlaubt euch – falls das einmal nicht der Fall ist – rechtzeitig Stakeholder einzubinden und darüber zu informieren, dass das Release Date nicht haltbar ist. Das kostet Mut, bringt aber auf Dauer mehr Vertrauen, als die Deadline wenige Wochen vor dem Release zu reißen.

Natürlich wird es immer wieder vorkommen, dass im Laufe der Arbeit neue nötige Funktionalität entdeckt wird – in diesem Fall kann diese ins Burn-Down aufgenommen werden, so dass sich die Auswirkungen auf die Deadline frühzeitig abschätzen lassen.

Ob ihr die User Stories, die ihr im Backlog Refinement aus den Epics generiert (das Runterbrechen in kleinere Einheiten), auch noch schätzt, ist im Grunde optional und hängt vor allem davon ab, ob ihr Epic nach Epic fertigstellt oder ob ihr in einem Sprint verschiedene User Stories aus verschiedenen Epics kombiniert. In ersterem Fall reicht es vermutlich, die Story Punkte der Epics im Burn-Down einzutragen und in Kauf zu nehmen, dass der Umfang der Epics gelegentlich falsch geschätzt wurde (was sich im Regelfall aber rausmittelt). In letzterem Fall solltet ihr die Stories schätzen, weil ihr sonst möglicherweise erst nach mehreren Sprints das erste Epic fertig stellt und so lange Zeit eure Velocity nicht einschätzen könnt.

Die Antwort ist eher ein Nein, wenn…

…euer Arbeitsumfeld so komplex ist, dass ihr nicht einmal einen groben Plan besitzt, welche Funktionalität ihr liefern wollt und wie diese aussehen könnte. Sprich: Wenn ihr jeden Sprint mitten in der Discovery seid und auf die Ergebnisse des letzten Sprints angewiesen seid, um die nächsten Schritte zu planen.

Wer in einem so volatilen Umfeld arbeitet (was für viele Teams gilt, die neue Features für vorhandene Plattformen bauen sollen, von denen nicht sicher ist, wie die Nutzer:innen darauf reagieren), der ist nicht in der Lage, eine verlässliche Liste an Epics/User Stories zu liefern, welche die Basis für ein Burn-Down-Chart wäre. Der Grund ist einfach, dass die Arbeit der nächsten Sprints noch nicht abschätzbar genug ist, um sie überhaupt aufschreiben zu können.

In diesem Fall kann die Funktion des Schätzens von User Stories eine andere sein: Statt langfristige Vorhersagen über Deadlines zutreffen, wird durch das Schätzen (dann per Planning Poker) ein gemeinsames Verständnis der User Story erzeugt. Im Planning Poker zeigen sich schnell unterschiedliche Vorstellungen davon, wie die Story umzusetzen ist, die dann diskutiert werden können. Das kann ein guter Grund für’s Schätzen sein – viele Teams haben aber gute Erfahrungen damit gemacht, darauf zu verzichten und einfach ungeschätzte Stories in ihren Sprint zu ziehen.

Die Frage, die sich für dich und dein Team also stellt, ist: Haben wir eine schätzbare, ungefähr verlässliche Liste an Funktionalität, die wir zu einer bestimmten Deadline liefern sollen? In diesem Fall ist es essenziell, die angesetzte Deadline mittels eines Burn-Down-Charts auf Machbarkeit zu überprüfen. Ist das nicht der Fall, weil ein Großteil der nötigen Funktionalität noch gar nicht entdeckt ist, könnt ihr euch diesen Schritt sparen und eure Sprints „auf Sicht“ fahren. Euer Ziel ist dann, Sprint für Sprint den zurzeit höchstmöglichen absehbaren Business Value zu liefern.

‍

geschrieben von Bernhard Eickenberg

‍