✁
digitalien.org — Stefan Knecht
Release Burn-Down Chart: wann ist mein feature fertig?
Die Grafik zeigt ein stilisiertes release burn-down.
Auf der vertikalen Achse sind die noch zu implementierenden Features aufgetragen, gemessen in story points als relative Aufwandschätzung. Auf der horizontalen Achse ist die Zeit bis zum geplanten Release-Datum aufgetragen.
Das release burn-down chart wird nach jedem Sprint aktualisiert.
Der Wert auf der y-Achse ‘schrumpft’ dabei um die story points der in diesem Sprint umgesetzten stories.
Diese Abnahme an ausgelieferten story points, also die abstrakt in Komplexität gemessene Umsetzungsleistung ist die velocity des Teams, die teamindividuelle Geschwindigkeit, ihr footprint, wenn man so will … das Muster, dass sich nach ein paar Sprints für jedes stabile Team zeigen wird und das keinesfalls eine Vergleichsgröße zwischen Teams ist!
Warum? Jedes Team kann andere Randbedingungen haben, andere domains und impediments. Ein Vergleich ist ist nicht nur fahrlässig sondern unmöglich.
Für ein einziges Team kann das release burn-down genutzt werden, um eine Prognose für die Zukunft zu erstellen und so Orientierung zu geben ob es möglich sein wird, den noch im Backlog vorhandenen Feature-Umfang bis zum geplanten Release-Termin umzusetzen.
Embrace Change — Änderungen? Gerne!
In der agilen Entwicklung wird es als normal und erwartbar erachtet, wenn mitten im Projektverlauf neue Feature-Wünsche dazukommen. ‘Embrace change’ bedeutet: heisse Änderungen willkommen. So ist die Welt nun mal, nichts bleibt, wie es scheint. Und auch der solideste Kalkulator kann kaum in die Zukunft sehen. Änderung geschehen, einfacher wird es, sich nicht dagegen zu wehren.
Es ist eine gute Praxis, diese neu hinzukommenden Features in einer anderen Farbe im Backlog zu markieren. Im obigen Beispiel ist dies der rote Balken unterhalb der Null-Linie.
Die blau gestrichelte Linie zeigt die Lieferprognose, wenn alles kommt, wie es soll. Das heißt: wenn dem Team nichts dazwischen kommt, die story-point-Schätzungen passen und … die velocity unverändert bleibt.
Die beiden roten Strichlinien zeigen die Prognosen für eine optimistische (steile Kurve links) bzw. pessimistische (flache Kurve rechts) Annahme für die velocity.
Kommt das Team mit der Umsetzung schneller voran (Kurve links): gute Chancen, dass der rote Bereich auch noch geliefert werden wird.
Treten Schwierigkeiten, impediments auf und die Dinge verzögern sich, sinkt die velocity und es werden weniger story points ausgeliefert. Natürlich werden nicht die Punkte geliefert sondern deren Äquivalent in Nutzen oder business value.
Dann zeigt der Schnittpunkt der rechten Linie mit dem Release-Datum, welche Features bis zu diesem Datum voraussichtlich fertig werden. Hoffentlich alle must-have-Features. Wenn dies nicht der Fall ist, kann der Product Owner frühzeitig mit seinen Stakeholdern über eine Verschiebung des Release-Datums nachdenken.
Das einfache burn-down chart erzeugt Transparenz. Schwierigkeiten mit dem Lieferumfang kündigen sich rechtzeitig an, um angemessen darauf reagieren zu können.
Das muss man aushalten lernen und das Backlog laufend und ausgewogen nach den Bedarfen aller Stakeholder priorisieren. Das ist ➚ Aufgabe des Product Owner, PO, Produktverantwortlichen — und nicht die Leichteste.