Release BurnDown Chart
Nach dem Sprint BurnDown Chart geht es heute eine Stufe weiter zum Release BurnDown Chart. Das ist eindeutig Janina Wohlerts Folge, daher kann sich Henry getrost zurücklehnen.
Also heute gibt es etwas mehr technisches Wissen, auch zu Metriken. Diese Folge hilft Dir dabei Dein Projekt etwas planbarer und vorhersagbarer zu machen.
Diese Folge auf YouTube: https://youtu.be/Qs809kRi2V0
Wie sieht es aus?
Es ist eine statistische Auswertung darüber, wie viel von meinem ursprünglich geplanten Umfang habe ich bereits erledigt?
Grundsätzlich ist es ein normales zweidimensionales Chart. Auf der Y-Achse wird die noch zu tuende Arbeit angezeigt und auf der X-Achse der jeweilige Sprint. Über die Kurven oder Linien ist dann zu erkennen ob der geplante Inhalt pünktlich zum Release abgearbeitet sein wird. Dafür braucht es natürlich Erfahrungswerte. Ich sehe auch, wie viel Arbeit hinzugekommen ist und kann planerisch auf das entsprechende Release einwirken. Beispielsweise durch Umpriorisierung.
Theoretisch wird die zu erledigende Arbeit (Release Backlog) von Sprint zu Sprint weniger und damit tendiert die Kurve oder die Balken in Richtung Nulllinie. Deshalb BurnDown, da die Arbeit abgebrannt wird.
Ich sehe also eine aufkummulierte Anzahl an User Stories, die ich mir für das Release vornehme.
Wenn mir nun auch noch die Velocity bekannt ist, kann ich eine Linie für die Abarbeitung anlegen und Aussagen über die Zukunft treffen.
Und Wozu?
Es hilft uns ähnlich wie das Sprint BurnDown Chart dabei zu sehen, wie viel Arbeit noch übrig ist. Dies ist vor allem für die Planung der ProductOwnerin und der Kommunikation mit ihren Stakeholderinnen wichtig.
Kernaussage: Schaffe ich das Release mit dem geplanten Umfang zum geplanten Zeitpunkt?
Wahrscheinlich darf ich an der Umfangsplanung etwas ändern. Und dies ist ja der Kern der Agilität. Wir halten Ressourcen, Zeit und Qualität stabil und schrauben am Umfang.
Entsprechend darf ich die Inhalte für mein Release, anhand der Hochrechnung auf dem BurnDown Chart eventuell anpassen. Es ist daher von dem Nutzen schon ähnlich einem Gantt-Chart aus dem klassischen Projektmanagement. Ich habe meinen Meilenstein (Release) und sehe, dass ich bei ein paar Funktionen aus der Zeit laufe und darf nun gegensteuern.
Ich sehe auch sehr gut, wie die Abarbeitungsquote ist und wie viel auf dem Weg vielleicht noch gelernt wird in Form von neuen Features und Anforderungen, die hinzukommen.
Den Termin verschieben
Eine weitere Möglichkeit, auf das nicht komplette Abarbeiten, zu reagieren ist den Release Termin entsprechend anzupassen. Dies kann mitunter eine never ending Story werden. Wir raten daher davon ab und halten lieber die Termine stabil. Das entspricht auch eher unserer Interpretation von Agilität.
Zusätzliche Arbeit
Wenn Du ein Produkt Agil entwickelst, dann werden auf dem Weg neue Erkenntnisse hochkommen und damit auch neue Anforderungen (User Stories). Diese kannst Du nun oben auf die Balken draufpacken oder unter die Nulllinie ergänzen. Beide Versionen sind üblich. Nun können wir den Arbeitsübergang zum pünktlichen Release sehr gut veranschaulichen.
Gleichzeitig bin ich aussagefähig in welchem Release denn theoretisch alles fertig wäre, wenn nichts neues mehr hinzukommt.
Warum machen wir kein Gantt Chart?
Ganz einfach: Weil wir nicht wissen was alles zu tun ist. Vor allem nicht zu Projektstart. Wozu also so viel Zeit in eine Planung investieren, der wir ab Tag 1 dann sowieso nur hinterher rennen? Das Release Burn Down Chart ist einfach und schnell gemacht. Die Aussagekraft bleibt die gleiche.
Meilensteine
Du könntest nun Meilensteine mit Releases gleichsetzen oder ein einziges Burndwon Chart für jedes Release machen. Auf jeden Fall empfiehlt es sich gleichmäßige Abstände für die Releases zu haben.
Das erste Release
Wie mache ich die Planung für das erste Release und das damit verbundene BurnDown Chart? Schätzen, das Team fragen und Erfahrungen sammeln. Also alles wie immer. 🙂
Also nimm Dir einen Tag mit der ProductOwnerin und anderen Interessierten, schreibt alle Features auf und macht einen groben Plan. Den mit einer guten Bauchschätzung ist oft genauso gut wie eine monatelange Planung.
Der Anfang
Wenn Du damit anfängst, dann legst Du erst einmal fest, wann Du ein Release machen möchtest. Also beispielsweise in 6 Sprints. Dann nehmt ihr euch die Summe X an Anforderungen vor für das Release. Dies wird auf dem Chart markiert. Diese werden aus dem Backlog dem Release zugeordnet.
Für wen?
In erster Linie ist ein Release BurnDown Chart ein Hilfsmittel für die ProductOwnerin. Vor allem um zu sehen wie viel Umfang im Release drin sein wird. Es ist gleichzeitig ein super Instrument um mit Stakeholdern kommunizieren zu können. Gleichsam hilft es auch der Transparenz gegenüber Kunden. Hast Du vielleicht schon einmal auf ein Release eines Spieles gewartet?
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉
In der Podcastfolge erwähnte Folgen zur Vertiefung:
Connecte dich gerne hier mit uns:
