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. 

Simon Flossmann
Simon Flossmann
Als Professional Scrum Trainer bei Scrum.org hilft Simon Scrum Masters, Product Ownern und Agile Leaders, Scrum effektiv einzusetzen, um agiler zu werden.

Noch mehr lernen

2 Kommentare zu „Warum Story Points nicht geeignet sind, um Releasedaten vorherzusagen“

  1. Hi Simon,

    ich verstehe das Problem, das Du ansprichst, kann aber mit Deiner Lösung nicht so ganz mitgehen.

    Wenn nach Scrum gearbeitet wird, arbeitet das Team ja in Sprints und die von Dir angesprochenen Verzögerungen wirken sich auch auf die Velocity aus.

    Alternativ zur durchschnittlichen Velocity kann ein Product Owner allerdings auch auf die Velocity Range zurückgreifen. (Hab ich hier ausführlich beschrieben: https://cdi.digital/burndown-chart/#vorhersagen-mit-der-velocity-range-treffen)

    Im Übrigen sollte es Standard sein, spätestens zur Review ein Update darüber zu geben, ob ein Release-Datum gehalten werden kann oder nicht. Sich zu Beginn eines Projektes auf einen fixen Scope und ein fixes Release-Datum festzunageln, bringt keinem etwas.

    Liebe Grüße
    Lars

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Ich freue mich, Dich kennenzulernen

Pascal Gugenberger

Pascal

Ich freue mich auf unser Gespräch!

Such Dir einfach einen Termin aus und wir quatschen.

Weiterleitung an Calendly, siehe Datenschutzerklärung.

Lust auf Input?

Newsletter

Melde Dich an und erhalte regelmäßig spannende Beiträge!