Burn-Down Charts sind eine Darstellungsform, bei der die in einem fest-definierten Zeitrahmen verbleibende Arbeit gegen die Zeit aufgetragen wird. Üblicherweise wird der (Projekt-)startpunkt auf x=0 gesetzt, und am rechte Ende der x-Achse befindet sich der Zielzeitpunkt (Deadline, Projektende, initiale Planung, Sprintende...). Auf der Y-Achse werden bei x=0 die ursprünglich geplante Arbeitsmenge aufgetragen, und für jeden Zeitpunkt wird die jeweils gültige Restarbeitsmenge (die Menge an Arbeit die noch getan werden muss, inkl. Changes oder Probleme) eingetragen. Da im Laufe des Projektes die Restarbeitsmenge abnimmt, geht der Graph nach unten – die "verbrannte Arbeit". Zum Zielzeitpunkt muss die Restarbeitsmenge auf 0 stehen. Mittels Burn-Down Chart lassen sich insbesondere mittelfristige Trends rechtzeitig entdecken.
Variationen
Es lassen sich je nach Projekt-Kontext unterschiedliche Dinge auftragen:
- Milestones/Releases oder Sprints/Iterationen statt absoluter Zeit
- Abstrakte Arbeitseinheiten wie Story Points/T-Shirt Größen
- konkret messbare Zahlenwerte (Ticketanzahl)
- Budgetkennzahlen oder anderweitig in Geld verrechnete Arbeit
Interpretationen
Durch die vergleichsweise einfach interpretierbare Aufbereitung lassen sich interessante Rückschlüsse auf das Vorhaben ziehen, sowohl für Aussenstehende als auch zur Reflektion im Team.
Extrapolation
Die Verlängerung der Linie von Ausgangs-Arbeitswert über aktuellen Wert zur Nullinie hin ergibt einen Prognose für den Fertigstellungszeitpunkt:
Interpretation der Abbildung: Aus der Abbildung lässt sich erkennen, dass das Vorhaben aktuell wahrscheinlich erst kurz nach der ursprünglich geplanten Deadline fertig wird. Allerdings wurde in den letzten 6 vergangenen Zeiteinheiten eine vorher aufgetretene Verzögerung (erkennbares Plateau in der Mitte der Kurve) wieder aufgeholt.
Durch Softwarunterstützung (oder genug Excel-Einsatz) lassen sich auch statische Analysen damit verbinden, die einen Prognosewert mit statischer Bandbreite für den Erwartungswert ausgeben:
Interpretation der Abbildung: Nimmt man den Korridor als 80% Wahrscheinlichkeit an, hat das Vorhaben durchaus hat eine Chance, im angepeilten Zeitraum fertig zu werden, eine Verspätung ist aber realistischer.
Korrelationen
Trägt man mehrere Kennzahlen übereinander in einem Chart auf, lassen sich aus abweichenden Kurvenverläufen Auffälligkeiten im Projekt (oder unbrauchbare Kennzahlen) aufdecken. Beispiel: Budgetverbrauch gegen "verbrannte" Ticketanzahl. Hiermit lassen sich insbesondere systematische Fehleinschätzungen oder schleichende Veränderungen (Scope Creep) identifizieren
Interpretation der Abbildung: Arbeit und gelieferte Features liefen zunächst parallel, in den letzten 6 Zeiteinheiten nimmt die Diskrepanz aber immer weiter zu. Die starke, und zunehmende Abweichung führt dazu, dass nach aktuellem Zeitpunkt das Budget verbraucht ist, bevor alle Features fertig sind und das Vorhaben zu Ende ist. Darüberhinaus zeigt die Extrapolation der Feature-Kurve an, dass man den angepeilten Feature-Umfang auch bei mehr Budget nicht zum Endzeitpunkt erreichen würde.
Nachträgliche Identifikation von Changes
Gibt es im Projekt eine gut ablaufendende Anforderungs/Ticket-Governance, lassen sich die Changes sogar nachträglich sehr gut identifizieren, und ihre Auswirkung messen: Changes zeichnen sich meistens dadurch aus, dass eine Kennzahl sich plötzlich stark verändert. Um dies zu erkennen kann man auch die Differenz einzelner Kennzahlen voneinander auftragen.
Anwendung im "klassischen Projektmanagement"
Obwohl die Herkunft des Burndown-Charts in Agilen Methoden begründet ist, ist die Anwendung nicht auf Agile Methoden beschränkt - es lässt sich genauso im klassischen Projektmanagement einsetzen. Im klassischen Projektmanagement lassen sich dabei insbesondere durch den Soll/Ist Vergleich Abweichungen und Trends aufdecken, und Rückschlüsse auf notwendige Maßnahmen aufdecken.
Anwendung
a) Sprint-BurnDown Chart (in Kombination mit EVA)
b) Release-BurnDown Chart
Kritik
Das Burn-Up-Chart
Da modernes Projektmanagement nicht "auf den einen ultimativen Zustand" hinarbeit, ist die Darstellungsweise mit einer Nulllinie unsinnig. Stattdessen spiegelt man den Graphen an der x-Achse, und trägt Erreichtes (oder eingesetzte Ressourcen oder Arbeit) auf. Dies lässt ihn dann nach oben zeigen - das sog. "Burn-Up"-Chart entsteht.
Erste Schritte
Da das Burndown-Chart sehr schnell erstellt ist, und sich aus vorhandenen Berichten/Daten erstellen lässt, lässt es sich sehr leicht einführen und pflegen, als erster Prototyp reicht meist sogar eine grobe Skizze auf einem Whiteboard. Wer das Chart mal ausprobieren möchte, sollte mal in seinem jeweiligen Projekt folgende Charts erstellen:
- Budgetverbrauch vs. Projektlaufzeit - klassischerweise liegen diese Daten sogar rückwirkend in den LA-Berichten vor. Achtung: Es ist nicht hilfreich, verbrauchtes Geld und verbrauchte Zeit im Burndown anzuzeigen. Wir brauchen immer ein Maß für Arbeit. Verbrauchtes Geld kann man dann nutzen, wenn die einzelnen Arbeitspakete fertig sind. Die Plankosten ersetzen damit die Story Points.
- gegen Sprint/Projektende bei IT-Projekten: Anzahl der Bugs vs. Restzeit vor Release. Hiermit lässt sich gut erkennen, ob man alle Bugs zum Release Zeitpunkt gefixt werden können. Diese Daten sind meist im Ticketsystem direkt abrufbar, ein täglicher aktuelles Chart (im Standup oder per Mail) ist sehr schnell erstellt und ermöglicht ein gutes Feedback für alle Beteiligten.
- Relatives Schätzen der Arbeitspakete zueinander: Alle Arbeitspakete werden auf Zetteln ausgedruckt und auf dem Tisch verteilt. Es wird ein Arbeitspaket mittlerer Größe festgelegt und willkürlich auf 5 Punkte gesetzt. Das ist die Referenz. Nun werden alle anderen Arbeitspakete ebenfalls in Relation zur Referenzstory verteilt (mehr, gleich groß, weniger). Als Punktwerte wird die Fibonacci-Reihe verwendet (1, 2, 3, 5, 8, 13, 21, 34, ...). Jede Woche wird überprüft, wie viele Arbeitspakete noch offen sind.
Beispiele aus der Praxis
Beispiel 1: Großprojekt - Release BurnDown
Projektrahmenbedingungen:
- Einführung neuartige Technologie inkl. Hardware (Pilot)
- zwei Standorte
- drei Teams (6 bis 8), Testteam separiert
- Projektumfeld: Einführung neuer Methoden, Werkzeuge und Prozesse; Unternehmen im Umbruch; zahlreiche Schnittstellen zur Linienorganisation usw. ergo: alles nicht so einfach
- Verwendung von Confluence und JIRA
ACHTUNG: Daten sind an einigen Stellen etwas überzeichnet, die Summe der Storypoints im Backlog sind jedoch echt. Auf die Angabe von Releases/Zwischenreleases und auf die "klassische" Darstellung als BurnDown mit Linie ist hier bewusst verzichtet worden. es soll gezeigt werden, dass man mit den Daten auch noch andere Auswirkungen zeigen kann.
Datenerfassung:
Für alle Teams werden die Werte in einer Seite eingetragen.
Wichtige Spalte: "Capacity" -> d.h. da im Projekt eben keine festen Temamitglieder sind, sondern diese auch noch andere Aufgaben haben, variiert die Verfügbare Kapazität in StoryPoints. Dies hat dann massiv Auswirkung auf Planung, Velocity und damit auf Zeit und Kosten. Um dies dem Topmanagement transparent zu machen eben die Form der Erfassung um damit die nächsten Grafike zu erzeugen.
Scope Change:
Grafik beantwortet die Frage: Wieviel Änderungen gab es pro Sprint? Dient dazu den PO zu erziehen und SprintInhalte nicht permanent umzuwerfen.
Velocity:
Keine stabilen Teams (Verfügbarkeiten unterschiedlich, ständiger Wechsel der Besetzung)
Forecast:
Beantwortet die Frage: Wann sollte es fertig sein (also der vom Mangement gesetzte Termin in rot) und die Realität dazu :-) als Folge von instabilen Teams, Überlastung der Organsiation etc.
ACHTUNG: Hier ist bewusst auf die klassiche Darstellung des BurnDown mit Linie verzichtet worden.
Das Ganze kann man jetzt noch mit verbrannten EUR hinter jeden Sprint legen und man bekommt relativ einfach auch eine EVA mit grottenschlechten SPI und CPI-Werten.
Weblinks
- Burndown-Chart im Artikel über Scrum auf Wikipedia.
- Artikel über Burndown-Chart in der englischen Wikipedia.
- Jeff Sutherland stellt in einem Interview vor, warum Burndown-Charts entwickelt wurden:
- Alistair Cockburn - BurnDown Charts und EVA ...http://alistair.cockburn.us/Earned-value+and+burn+charts
Attachments:
image2014-10-1 12:43:21.png (image/png)
image2014-10-1 12:45:41.png (image/png)
image2014-10-1 12:55:42.png (image/png)
Release_Burndown-demo-daten.jpg (image/jpeg)
Release_Burndown-demo_scopechange.jpg (image/jpeg)
Release_Burndown-demo-Chart.xlsx.jpg (image/jpeg)
Release_Burndown-demo-velocity.jpg (image/jpeg)
Release_Burndown-demo-daten.jpg (image/jpeg)
Release_Burndown-demo-forecast.jpg (image/jpeg)
Comments:
Zu Link Nr. 4: Alistair Cockburn beschreibt in dem Artikel nicht, dass EVA nicht funktioniert. Er schreibt, dass wir Burn-Downs brauchen und dass wir das richtige Maß für Arbeit finden müssen.
Posted by jan.fischbach at 09. Okt 2014 10:51
|
Jan Fischbach Du darfst das gerne einfach im Artikel korrigieren; darum ist es ja ein Wiki.
Posted by mraitner at 09. Okt 2014 11:07
|
hab den Text jetzt geändert....
Posted by rsagb at 09. Okt 2014 11:25
|