Sessiondokumentation zum Thema Release Planung in agilen Projekten.

Motivation

Agile Projekte haben, im Gegensatz zu Wasserfall-Projekten, die Eigenschaft, dass sie über den Scope gesteuert werden. Budget und Zeit ist fix, der Scope variabel.

Kunden haben sehr oft den Bedarf zu wissen, was sie für ihr Geld bekommen und wie lange es dauert, bis sie die gewünschten Features bekommen. Diese Informationen zu haben hilft auch in der Kundenkommunikation.

Business Value in Abhängigkeit zur Zeit

Zeichnet man die erreichten Story Points (Buisness Value) eines Teams als eine art kummuliertes BurnUp Chart über die Zeit, entsteht die im nachfolgenden Bild zu sehende rote Kurve.

Die minimal bzw.maximal Werte ergeben den Korridor in dem sich das Team während der Umsetzung bewegt (der Durchschnitt davon ergibt die Velocity).

Voraussetzung für einen solchen Graph ist eine gewisse Menge an Daten. Je mehr Sprints das Team bereits zusammen gearbeitet hat, desto genauer die Daten.

Fester Scope / variable Zeit

Betrachtet man nun einen fixen Scope (blaue Kurve), ergeben sich aus dem Korridor zwei mögliche Fertigstellungstermine.

Voraussetzung für diese Vorhersage ist ein entsprechend gepflegtes Backlog. Das Backlog muss entweder:

1. Detailliert genug sein, um so weit in die Zukunft zu schauen oder
2. Man wendet eine Methode wie Magic Estimation an, um eine große Menge des Backlogs im Voraus zu schätzen

Feste Zeit / variabler Scope

Gibt es, z.B. vom Kunden vorgegeben, einen festen Release-Termin (graue Kurve) gibt es einen minimalen und einen maximalen Scope den das Team, auf Grundlage der gesammelten Daten, schaffen kann.

Trimestrierung der Entwicklungszeit

Um zum Ende eines Releasetermins sicher zu sein, dass der gewünschte Business Value auch umgesetzt und ausgeliefert werden kann, sollten nach 1/3 der Umsetzungszeit folgende Artefakte verfügbar sein:

• komplexe und risikobehaftete Themen werden zuerst bearbeitet (Risikominimierung bei Verkürzung der time-to-market)
• Bereitstellung einer Produktivumgebung
• Entwicklungsumgebung anpassen, um sie technisch nah genug an die produktivumgebung zu bringen
• CI / CD Prozesse

Nach 2/3 der Zeit, sollte ein Release 1.0 als full build auf der Produktivplattform möglich sein. Das letzte Trimester ist dann für die weitere Entwicklung von notwendigen Features und weiterer Defectbehebung notwendig.

Daraus ergibt sich die logische Konsequenz zum Abschnitt "Business Value in Abhängigkeit zur Zeit" die Notwendigkeit auf den Termin nach 2/3 der Zeit zu planen.

Relative Schätzung zwischen Releases

Als Voraussetzung für die Relative Schätzung von Relases eignet sich eine User Story Map. Als Spalten der Map werden die Releases gewählt.

Füllt man das erste Release mit entsprechend verfeinerten und schätzbaren User Storys ist es mit der oben beschriebenen Methode möglich, die Dauer bis zur Umsetzung des ersten Releases (mit der beschriebenen Unschärfe) zu schätzen.

Das Team kann nun die Komplexität des Releases 2 in Abhängigkeit zu Release 1 schätzen.

Beispiel: Dauert die Umsetzung des ersten Releases 6 Sprints und wird das Release 2 als 1,5 mal so komplex eingeschätzt, kann daraus geschlussfolgert werden, dass das zweite Release nach etwa 9 Sprints fertiggestellt sein wird.

Durchschnittliche Zeitdauer einer User Story

Zusätzlich, kann mit entsprechend großem Datenbestand, bei ähnlicher technischer Umgebung und stabilem Team, die durchschnittliche Dauer zur Umsetzung einer User Story berechnet werden. Daraus kann wiederum nach der oben beschriebenen Methode oder bei der Abschätzung des Umfangs eines Releases die Dauer zur Umsetzung berechnet werden. Umso mehr Daten vorhanden sind, desto genauer die Methode. Die Unterschiede (maximal und minmal Dauer der Storys) nivellieren sich über die Zeit.

Danke

Vielen Dank für den Input in der Session geht an:

• Marco Franz (@enzocalzone) und
• Paul Hilmer (@paul_hilmer)

Als Quelle diente das Video "Agile Product Ownership in a nutshell" von Henrik Kniberg