Warum Story Points nicht geeignet sind, um Releasedaten vorherzusagen

Die Chancen stehen gut, dass dein Team jeden Sprint erneut vor folgendem Problem steht:

Einerseits möchtet ihr die Einträge im Product Backlog vor dem Sprint in Story Points schätzen, um die Komplexität der Arbeiten besser zu verstehen. Andererseits sollt ihr gegenüber dem Kunden ein Datum angeben, wann das Feature geliefert wird. Wir haben also immer wieder diese Schwierigkeit: 

Dein Team schätzt in Punkten, aber der Kunde möchte ein Datum. 

Der häufig empfohlene Ausweg

Der Ausweg aus diesem Problem, welchen selbst erfahrene Agile Experten und Scrum Coaches vorschlagen, lautet:

1. Es soll ein Commitment abgegeben werden, wann ein Eintrag aus dem Product Backlog fertig ist. Die Story Points aller Einträge bis zu diesem Eintrag im Backlog müssen dann aufsummiert werden. 
2. Wenn du nun die durchschnittliche Velocity mit der Anzahl der verfügbaren Personentage im Sprint in Relation setzt, dann weißt du, wie lange es dauert, bis ein Story Point abgearbeitet ist. 
3. Mit der Umsetzungszeit und der Anzahl der verbleibenden Story Points kannst du das Fertigstellungsdatum für diesen Eintrag exakt benennen. 

Warum kann das nicht funktionieren?

Dafür gibt es viele Gründe. Angefangen damit, dass sich die Arbeit als komplexer als angenommen herausstellt, sich die Teamstruktur ändert oder es Probleme mit dem Produktionssystem gibt. Der mit Abstand banalste Grund besteht allerdings darin, dass Story-Point-Schätzungen nicht implizieren, dass auch konstant daran gearbeitet wird. Oder in anderen Worten: Wie viel Arbeit etwas ist und wie lange es dauert, sind zwei unterschiedliche Dinge!

Ein kleines Gedankenexperiment, um die Aussage zu veranschaulichen: Nehmen wir an, für einen Eintrag im Product Backlog wird die Arbeit auf 5 Personentage geschätzt. Dann könnte die Arbeit in einem Tag abgeschlossen werden, wenn 5 Entwickler parallel daran arbeiten. Wenn die Entwickler ihre Arbeit aber nacheinander erledigen, dauert die Fertigstellung trotzdem 5 Tage. In Realität kommen jetzt noch viele andere Verzögerungen hinzu. Wir müssen Wochenenden, Feiertage, Urlaubstage, Krankheiten und unzählige andere Gründe berücksichtigen, warum an diesem Eintrag im Moment nicht gearbeitet wird. Wir sehen also, dass der Fertigstellungszeitpunkt nicht nur von der Komplexität oder dem Umfang der Arbeit abhängt, sondern von vielen weiteren Faktoren. 

Deshalb eignen sich Schätzungen nicht, um Fertigstellungstermine vorherzusagen. 

In dieser Einsicht liegt auch die Lösung des Problems, die viele Experten nicht kennen:

Lead Time und Cycle Time stellen die Lösung des Problems dar

Anstatt die Frage, wann ein Feature fertig sein wird, basierend auf Story-Point-Schätzungen zu beantworten, kann sie auch mit der tatsächlichen Fertigstellungszeit beantwortet werden. 

Hierzu solltest du zwei Kennzahlen heranziehen: 

Du kannst die gesamte Zeit messen, die ein Einträge im Product Backlog verbleibt. Sie wird als Lead Time bezeichnet und beschreibt die Zeit von der Erstellung eines Eintrags im Product Backlog bis zu dessen Auslieferung an den Kunden. Durch das Festhalten der Lead Time der vergangenen Einträge im Product Backlog ist dein Team nun in der Lage, die Frage wie folgt zu beantworten: Für die Umsetzung eines Eintrags aus dem Product Backlog hat das Team in der Vergangenheit im schnellsten Fall einem Tag gebraucht, bis der Eintrag fertig war, und im langsamsten Fall bis zu 122 Tagen.

Möchte ein Stakeholder wissen, wann er mit einem Eintrag rechnen kann, an dem bereits gearbeitet wird, liefert ihm die Cycle Time darüber eine Auskunft. Die Cycle Time beschreibt die Zeit vom Beginn der Bearbeitung eines Eintrags im Product Backlog bis zu dessen Fertigstellung. Sie erlaubt Antworten der Form: Wenn unser Team mit der Umsetzung dieses Eintrags beginnt, dann hat es in der Vergangenheit im besten Fall einen Tag gedauert, bis der Eintrag fertig war, und im schlimmsten Fall bis zu 30 Tagen. 

Vorteile für dein Scrum Team 

Führst du Lead-Time- und Cycle-Time-Metriken in deinem Team ein, ergeben sich für dein Team folgende Vorteile: 

• Diese Vorhersagen basieren nicht auf Schätzungen. Sie spiegeln einfach die reale Vergangenheit wider. 
• Dein Team kann weiterhin Story Points verwenden, um die Komplexität der Arbeit besser zu verstehen. 
• Dein Scrum Team kann auch weiterhin Velocity verwenden, um zu bestimmen, wie viele Einträge ihr in den aktuellen Sprint aufnehmen solltet. 
• Es entsteht keine weitere Arbeit für dein Team, denn die bekannten Backlog-Management-Programme stellen diese Kennzahlen automatisch zur Verfügung. 
• Dein Team kann die Frage, wann ein Eintrag aus dem Backlog fertig sein wird, in der richtigen Größeneinheit dafür beantworten: in Zeit!
• Stakeholder können die Fragen, wann ihr Eintrag fertiggestellt wird, weitestgehend selbst beantworten. Du musst den Stakeholdern nur diese Kennzahlen zusammen mit dem Product Backlog als Dashboard zur Verfügung stellen.

Um erfolgreich zu sein, sollte dein Team Schätzungen und Vorhersagen verwenden

Schätzungen sind nicht geeignet, um Vorhersagen zu treffen. Das bedeutet nicht, dass Scrum Teams jetzt auf das Schätzen der Arbeit verzichten sollen. Aus meiner Sicht braucht es beides.

Die Herausforderung besteht darin, dem Wunsch zu widerstehen, alle Fragen mit einer Kennzahl beantworten zu wollen.