Folge 083 BurnDown Chart

BurnDown Chart

Heute geht es, endlich wieder mit Janina, um das BurnDown Chart.
Ein Artefakt aus dem Scrum. Nicht im Scrum Guide beschrieben und
trotzdem ein nützliches Artefakt.


Also, wenn Du neben dem Board nach einem möglichen Artefakt im
Scrum suchst, könnte das BurnDown Chart eine Antwort sein.


Diese Folge auf YouTube: https://youtu.be/-RVYdu4ZdWs
Wofür?

Und jetzt Vorsicht! Wir können das BurnDown Chart nutzen um zu
überprüfen, wie der Sprint läuft. Das ist für alle Menschen im
Team nützlich um ein gutes Gefühl für die Abarbeitung zu
bekommen. Also Scrum Masterin, Product Ownerin und Entwickler. Es
ist keine Kontrolle! Es geht nicht darum wer gute Arbeit macht
oder das Team zu gängeln, sondern um Hinweise auf die Abarbeitung
zu bekommen. Wir sehen so ab der Hälfte eines Sprints, ob das
vorgesehene Commitment realistisch bleibt. Eventuell gab es
Störungen, die die Abarbeitung behindern. Dann können wir
entsprechend anpassen.


Das Team ist doch selbstorganisiert! Ja ist es und wenn alles
funktioniert, fein. Das Chart ist lediglich ein Frühwarnsystem
und schnell erstellt.
Der Aufbau des Chats

Es ist ein zweidimensionales Diagramm mit zwei Achsen. Auf der
vertikalen Achse wird die noch zu erledigende Arbeit im Sprint
gemessen. Henry nutzt dafür gern Tasks, Janina lieber
StoryPoints. Du kannst auch Stories zählen oder eine beliebige
andere Größe nutzen. Janina nutzt unter anderem lieber
StoryPoints, da diese die Komplexität gleichsetzen. Denn wir
möchten ja wissen wie viel Komplexität das Team bereits bewältigt
hat oder noch vor sich hat.


Auf der horizontalen Achse ist die Zeit in Form von Sprinttagen.
Also jeder Datenpunkt ist ein Sprinttag.


Jetzt tragen wir als aller erstes auf der vertikalen Achse die zu
erledigende Arbeit ein. Beispielsweise 40 Tasks. Das Team wird
diese nun Stück für Stück abarbeiten, so dass die Arbeit weniger
wird. Das sehen wir im Graphen und deshalb heißt das Chart
BurnDown Chart.


Nun kannst Du eine Linie zwischen dem Vorgenommenem und dem
letzten Sprinttag ziehen. Also eine gerade Linie von in unserem
Beispiel 40 Tasks zu 0 Tasks am letzten Tag. Das ist die
Ideallinie, wie ein perfekter Sprint theoretisch laufen könnte.
Entspricht natürlich selten der Realität, also trägst Du oder das
Team jeden Tag die entsprechend noch offene Arbeit ein. Zu große
Abweichungen vom Ideal könnten ein Indiz für Gesprächsbedarf
sein.
Verwendung

Es ist kein Kontrollinstrument für das Team und das Dokument
gehört dem Team. Nicht dem Management oder sonst wem. Das Team
ist daher auch für die Aktualität verantwortlich. Es ist völlig
normal, dass sich der reale Graph gerade am Anfang erst einmal
horizontal bewegt. Keine Panik! Erst ab der Mitte des Sprints
kannst Du das BurnDown benutzen um das Team einmal vorsichtig zu
fragen ob sie glauben noch alles im Sprint befindliche zu
schaffen. Wenn die Antwort ja ist, alles fein. Sie sind
selbstorganisiert. Das BurnDown ist lediglich ein Hilfsmittel.


Sollte das Team so selbst feststellen, dass nicht mehr alles
schaffbar ist oder die Zuversicht verlieren, dann dürft ihr
gemeinsam den Sprint umgestalten und Maßnahmen treffen.


Verläuft der Sprint nicht ideal, und das ist ganz normal, dann
hilft das BurnDown auch der Product Ownerin bei der Vorplanung
des nächsten Sprints. Es gibt schließlich einen Übertrag.
StoryPoints vs Tasks messen

Jetzt haben wir zwei sehr unterschiedliche Ansätze gehört, was
man messen könnte. StoryPoints zeigen vor allem die Komplexität
und werden nur gezählt, wenn die Story auch wirklich erledigt
ist. Der Maler bekommt also erst sein Geld, wenn er aufgeräumt
hat. Bei Tasks ist das anders. Da diese nur die Größe eines Tags
haben passiert dadurch gleichzeitig viel mehr Bewegung auf dem
BurnDownChart und gleichzeitig schafft es eine trügerische
Sicherheit. Dafür hilft die Taskdarstellung das BurnDown vom
Velocity Chart zu trennen. Henry sieht auf diese Weise, wenn die
Abarbeitungsquote abweicht, da Tasks plötzlich länger dauern. Ein
gutes Indiz dafür, dass vielleicht Störungen von außen
auftauchen. Tolles Thema für die nächste Retrospektive!


Du merkst schon, das Chart dient als Diskussionsgrundlage und um
die Kommunikation mit Zahlen zu untermauern.
Don’t Panic!

Ich habe eine krasse Abweichung und nun? Weiterhin ruhig bleiben,
es ist normal. Frag das Team „Habt ihr das Gefühl den Sprint noch
zu schaffen?“. Das schafft Psychologische Sicherheit. Sie tragen
schließlich die Verantwortung dafür und diese dürfen wir bei
ihnen belassen. Warte ein paar Tage und wenn es sich nicht
bessert, dann vielleicht einmal konkreter fragen, warum Deine
Statistik von deren Gefühl abweicht. Vielleicht hast Du etwas
Entscheidendes übersehen. Und wenn es doch nicht klappt, dann ab
damit in die Retrospektive.
Anzahl Teammitglieder

Henry misst gern noch die Anzahl Teammitglieder an jedem Tag.
Nicht einzelne Personen, sondern nur die Gesamtsumme. Dies gibt
manchmal Aufschluss darüber, warum es an einem Tag Abweichungen
gab. Beispielsweise hohe Krankheitsfälle.
Messzeitpunkt

Ich empfehle das Daily als Messzeitpunkt.


 


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:


Scrum

Scrum Guide

Board

Team

Commitment

Selbstorganisation und Visionen

StoryPoints

Komplexität

Retrospektive



Connecte dich gerne hier mit uns:


LinkedIn


Instagram


YouTube


Facebook


Webseite


Facebook-Gruppe


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