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.

Holz wird verbrannt - Burn Down - Ein Chart brennt die Hütte ab!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:


Connecte dich gerne hier mit uns:

LinkedIn

Instagram

YouTube

Facebook

Webseite

Facebook-Gruppe

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert