Folge 089 Release BurnDown Chart

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,


Janina & Henry


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:


Sprint BurnDown Chart

Story Points

Scrum Guide

Komplexität

ProductOwnerin

Agilität

Qualität



Connecte dich gerne hier mit uns:


LinkedIn


Instagram


YouTube


Facebook


Webseite


Facebook-Gruppe


The post Folge 089 Release BurnDown Chart appeared first on
Znipcast - für gute Zusammenarbeit | Agile, Scrum, KanBan,
Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy.