Schätzungen sind out, Prognosen sind in

«NoEstimates kann nicht funktionieren, weil die meisten vorausplanen wollen.» Kommt Ihnen das bekannt vor? Tatsächlich bedeutet NoEstimates (Deutsch: keine Schätzungen) nicht das Fehlen jeglicher Prognosen und Vorausplanungen. Ganz im Gegenteil: Durch die Nachverfolgung des Team-Durchsatzes und einem schlanken Entwicklungsprozess kann die Planung zuverlässiger werden – obwohl keine einzige Story geschätzt wird.

Doch wie sieht das in der Praxis aus? Anstatt für jede User Story in Ihrem Backlog ein zeitfressendes Schätzspiel zu spielen, bekommen Sie viel schneller und oft ähnliche Ergebnisse, wenn Sie anhand der vergangenen Daten und gezählten Storys eine Prognose erstellen. Während Schätzungen typischerweise nur den Entwicklungsaufwand berücksichtigen, ist die Durchlaufzeit der einzelnen Storys eine viel bessere Kennzahl.

Um den Durchsatz und die entsprechende Durchlaufzeit zu erhalten, brauchen Sie unbedingt einen definierten (und hoffentlich schlanken) Value Stream. Ein typischer Value Stream für eine Story sieht oft so aus: «Neu» -> «Bereit» -> «In Bearbeitung» -> «Fertig» (New -> Ready -> Doing -> Done). «Fertig» bedeutet im Idealfall «verfügbar für den Kunden», und nicht «bereit für die interne QS».

Die wichtigste Kennzahl für die Planung ohne explizites Schätzen ist der Story-Durchsatz. Wenn Sie später das System optimieren möchten, ist es sinnvoll, zusätzlich die Durchlaufzeit (d. h. wie lange eine Story in jedem Stadium verbleibt) als verwandte Kennzahl nachzuverfolgen. Der Durchsatz lässt sich ganz leicht berechnen, indem Sie die Anzahl der gelieferten Storys durch die verstrichene Zeit teilen:

throughput = number_of_stories / number_of_workdays

Falls die Kapazität auf Dauer deutlich schwankt, kann es hilfreich sein, Urlaube und andere geplante Abwesenheiten einzubeziehen.

Bei einem schlanken Entwicklungsprozess befinden sich gerade genug Storys im Stadium «Bereit», damit dem Team niemals die Arbeit ausgeht. Das lässt sich gut mit einem kumulativen Flussdiagramm visualisieren. Wenn der Bereich «Bereit» (Ready) etwa genauso dick oder etwas dicker ist als der Bereich «In Bearbeitung» (Doing), dann hat das Team einen schlanken Arbeitsansatz.

Da wir den Eingang von Storys genau kontrollieren können, aber ab dem Stadium «In Bearbeitung» nur noch reaktiv sind, setzen wir hier mit der Messung an. Mit häufigeren Refinement-Meetings können wir unmittelbar die Durchlaufzeiten in den Stadien «Neu» (New) und «Bereit» (Ready) beschleunigen und die Anzahl der Storys in «Bereit» erhöhen. Wenn wir den Durchsatz und die Varianz unseres Entwicklungsprozesses kennen, können wir sehr zuverlässige Prognosen treffen.

Am besten lässt sich die Varianz mit der Durchlaufzeit der Storys messen. Wenn wir diese Durchlaufzeit in ein Diagramm eintragen, ergibt sich typischerweise eine Gausssche Glockenkurve. Ist die Kurve eher flach und breit als steil und schmal, dann ist das System volatiler und Vorhersagen sind in der Regel weniger präzise. Aber das ist nicht unbedingt schlimm, es sollte nur bedacht werden. Bei einer sehr grossen Varianz in den Durchlaufzeiten kann die Aufteilung der Storys helfen, hier mehr Konstanz im Durchsatz zu erhalten.

Prognosen erstellen

Mit den Daten für den Durchsatz und dem kumulativen Flussdiagramm (KFD) als Basis ist es ganz einfach, eine Prognose hochzurechnen. Hat ein Team zum Beispiel sechs Iterationen und 21 Storys fertiggestellt, erhalten wir einen mittleren Durchsatz von 3,5 Storys pro Iteration. Wenn wir die schnellste Iteration ignorieren, könnte sich der Durchsatz auf 3,1 Storys pro Iteration verringern, und wenn wir die langsamste ignorieren, könnte er sich auf 3,9 erhöhen (alle Zahlen in diesem Beispiel sind frei erfunden.) Wenn wir nun eine Linie auf das KFD zeichnen, erhalten wir anhand dieser Zahlen eine Vorhersage darüber, wie viele Storys zu welchem Zeitpunkt zukünftig fertiggestellt werden.

Das könnte in etwa so aussehen: Wenn wir dieses Vorgehen regelmässig anwenden und das Zeitfenster vergrössern, erhalten wir eine immer präzisere Prognose. Die Prognose ist das Story-Budget, das dem Team, inklusive PO, für eine bestimmte Zeit zur Verfügung steht. Für eine noch präzisere Prognose kann die gerade Linie je nach anstehenden Engpässen wie Urlauben, Neuanstellungen und Schulungen angepasst werden. Falls Sie statt der Iterationen Kanban nutzen, funktioniert für Prognosen auch ein angemessener Zeitrahmen von z. B. 1 bis 2 Wochen. Umso mehr wir die Daten hochrechnen, umso unsicherer wird unsere Prognose. Daher ist eine häufige Anpassung auf Basis der aktuellen Daten und eine entsprechende Kommunikation mit den Stakeholdern ein Muss.

Fazit

Durch häufige, datengestützte Prognosen über den gesamten Entwicklungsprozess hinweg ist eine vorausschauende Planung möglich, ohne eine einzige Schätzung für eine Story abgeben zu müssen. Eine solche Planung kann sogar zuverlässiger sein als eine Erstschätzung, da nicht nur der Implementierungsaufwand, sondern der gesamte Entwicklungsprozess berücksichtigt wird. So wird der Entwicklungsprozess genau an den Schmerzpunkten optimiert, anstatt dass versucht wird, nächstes Mal einfach besser zu schätzen. Und das ist nur einer von vielen Vorteilen. Indem wir die Storys in minimale, aber wertvolle Slices unterteilen, richtet sich unser Fokus darauf, was Wert bringt, anstatt was günstig ist – wir fragen uns nicht mehr «Was kostet das?», sondern «Was gewinnen wir?». Also, hören Sie auf zu schätzen und fangen Sie an, Prognosen zu stellen und Wert zu liefern!

Dieser Text erschien zuerst auf Englisch im Blog von Dominic Berner.