t2informatik » Wissen kompakt » Burn-Down-Chart

Burn-Down-Chart

Die Darstellung der Restaufwände

Ein Burn-Down-Chart ist eine grafische Darstellung von Restaufwänden in Relation zur verbleibenden Zeit in einem definierten Zeitintervall. Einfach ausgedrückt: es zeigt den verbleibenden Aufwand für noch zu erledigende Tätigkeiten im Zeitverlauf. Das Burn-Down-Chart ist ein Liniendiagramm, dass zur Vorhersage genutzt wird, ob die geplante Arbeit bis zum geplanten Zeitpunkt erledigt sein wird.

Häufig wird das Burn-Down-Chat in agilen Entwicklungsprojekten, insbesondere bei einem Vorgehen nach Scrum, verwendet; entsprechend wird es auch als Sprint Burndown bezeichnet. Grundsätzlich lässt es sich aber in allen Projekten – also bspw. auch für Iterationen oder Releases – nutzen, bei denen der Fortschritt bzw. Fertigstellungsgrad messbar ist. Der Begriff „burn down“ signalisiert dabei, wie viel Arbeit bereits erledigt wurde; eine Übersetzung ins Deutsche im Sinne von „verbrannter Arbeit“ ergibt allerdings nur wenig Sinn.

Als Instrument der Projekt- und Entwicklungskontrolle bietet das Burn-Down-Chart einige Vorteile:

  • Mit ein bisschen Übung ist es leicht zu verstehen (siehe Beispiele weiter unten).
  • Es bietet eine schnelle Übersicht, über die noch zu leistenden Aufwand im Sprint, in der Iteration oder im Projekt.
  • Es visualisiert den Status quo der geleisteten zur geplanten Arbeit zu einem Stichtag. In anderen Worten: es zeigt den Stand der Arbeit zum aktuellen Tag.

Damit es diese Vorteile entfalten kann, gibt es auch einige Voraussetzungen für die Verwendung des Diagramms:

  • Es muss ein gemeinsames Verständnis für den Aufbau des Diagramms geben. Relativ üblich ist die Anzeige der Restaufwände in Stunden an der Y-Achse des Burn-Down-Charts. Möglich sind aber auch bspw. Storypoints oder Tasks. An der X-Achse werden in den allermeisten Fällen die Tage bis zum Ende des definierten Zeitintervalls  dargestellt. Zumindest theoretisch könnten auch alternative Daten wie bspw. Meilensteine verwendet werden.
  • Es muss kontinuierlich gepflegt werden, denn nur so lassen sich relativ valide Annahmen treffen. Dazu schätzt jedes Teammitglied täglich den Restaufwand seiner Aufgaben, die anschließend kumuliert im Diagramm ausgewiesen werden.
  • Der Restaufwand muss für die Teammitglieder schätzbar sein, d.h. die zu erledigenden Aufgaben müssen in einer sinnvollen Granularität geplant sein. Durch neue Erkenntnisse kann es dann auch passieren, dass Restaufwände höher als einen Tag zuvor eingeschätzt werden. 

Wie ist ein Burn-Down-Chart zu interpretieren? Werfen wir einen Blick auf verschiedene Beispiele:

Burn-Down-Chart

Im ersten Beispiel „Der ideale Verlauf“ sehen Sie eine gestrichelte Linie, die eine proportionale Abnahme der Restaufwände im Zeitverlauf darstellt. Zu Beginn der Iteration, des Sprints oder allgemein des definierten Zeitintervalls ist der Restaufwand maximal, da noch nicht mit der Realisierung der Aufgaben begonnen wurde. Am Endes des Zeitintervalls ist der Restaufwand gleich null, alle Aufgaben sind also abgearbeitet. Soweit zur Theorie – wie kann es nun in der Praxis aussehen?

Im Beispiel „Das Ziel ist erreicht“ sehen Sie einen relativ normalen Verlauf: erst war das Team etwas schneller als geplant (die farbige Linie liegt unter der gestrichelten, die den durchschnittlichen Verlauf anzeigt), dann war es ein wenig langsamer (die farbige Line verläuft oberhalb der gestichelten Linie). Kurz vor Ende des Intervall lag das Team wieder vor dem Plan (die farbige Linie liegt wieder unterhalb der gestrichelten Linie) und zum Ende wurde das Ziel erreicht (Restaufwand gleich null).

Im Beispiel „Die reduzierten Aufgaben“ sehen Sie (mittig im Diagramm) eine senkrechte Linie. Dies bedeutet, dass im Laufe des Intervalls an diesem Tag die Aufgaben reduziert wurden. Vermutlich hätte das Entwicklungsteam ansonsten das Ziel – bspw. ein Sprint-Ziel – deutlich verfehlt. Die genaue Ursache für die Reduzierung der Aufgaben lässt sich aber nicht aus dem Burn-Down-Diagramm ablesen (siehe Kritik bzw. Grenzen der Darstellung).

Im Beispiel „Die zusätzlichen Aufgaben“ sehen Sie das genaue Gegenteil vom Beispiel zuvor: das Team lag so gut im Plan, dass es noch zusätzliche Aufgaben übernehmen konnte, so dass es an einem Tag einen senkrechten Anstieg der Restaufwände gibt. In einem solchen Fall handelt es sich also nicht um einen Sprint nach den Regeln von Scrum, denn dort bleibt der Umfang während des Sprints unangetastet.

Im Beispiel „Der Abbruch“ ist bestenfalls ein marginaler Fortschritt im Zeitverlauf zu erkennen, so dass das Team die Reißleine gezogen und das Zeitintervall vorzeitig beendet hat.

Und im letzten Beispiel sehen Sie einen treppenförmigen Verlauf. Dies ist ein klares Indiz, dass das Diagramm nur sporadisch gepflegt wurde, denn immer zum Zeitpunkt der Aktualisierung sanken die Restaufwände auf das Niveau der idealen Linie.

Bei aller Einfachheit der Darstellung gibt es auch einige Kritikpunkte bzw. Grenzen des Burn-Down-Charts:

  • An sich geht die Darstellung davon aus, dass im betrachteten Zeitraum dieselbe Anzahl von Mitarbeitern mit gleichbleibender Kapazität an der Abarbeitung der Aufgaben beteiligt sind. Das ist in vielen Organisationen so nicht möglich, da Mitarbeiter häufig in mehreren Projekten gleichzeitig agieren, neben Projektarbeiten auch Linientätigkeiten durchführen, ab und an in Urlaub gehen oder gar kurzfristig krank werden. Selbst in Scrum gibt es immer wieder Impediments, die die kontinuierliche Arbeit an definierten Tasks zumindest einschränkt.
  • Der Vergleich zwischen dem idealisierten Soll und dem tatsächlichen Ist (der zudem noch abhängt von der Fähigkeit einzelner Mitarbeiter ihre Restaufwände gut schätzen zu können) ist bestenfalls ein Indikator, ob ein definiertes Ziel in einem definierten Zeitfenster erreicht werden kann; mehr ist es aber nicht.
  • Die Gründe für Probleme, Verzögerungen oder schnelleres Arbeiten lassen sich nicht aus der Darstellung ablesen. Bspw. könnte eine Abweichung an der guten oder schlechten Produktivität des Teams liegen, möglicherweise liegt es aber auch an ungenauer Planung oder kurzfristig hinzugekommene Aufgaben. In manchen Publikationen ist auch von Überlastung und Unterforderung des Teams die Rede – solche Informationen lassen sich aber nicht aus dem Diagramm ablesen.
  • Bei grundsätzlicher Unterschätzung der Restaufwände wird das Burn-Down-Chart bis kurz vor Ende des Betrachtungszeitraums immer positiv aussehen (die farbige Linie unterhalb der gestrichelten) und damit nicht die Realität widerspiegeln. Entsprechend verhält es sich bei einer kontinuierlichen Überschätzung.

Der Scrum Guide charakterisiert das Burn-Down-Chart – und das alternative Burn-Up-Chart selbst wie folgt: „Zur Fortschrittsprognose werden diverse Planungspraktiken wie Burndown- oder Burnup-Diagramme eingesetzt. Diese haben sich als nützlich erwiesen, allerdings ersetzen sie nicht die Wichtigkeit des empirischen Vorgehens. In komplexen Umgebungen lassen sich zukünftige Ereignisse nicht vorherbestimmen. Nur was geschehen ist, gibt Anhaltspunkte für die zukunftsgerichtete Entscheidungsfindung.“ In anderen Worten: es handelt sich um EINEN Indikator, ob die geplante Arbeit zum geplanten Zeitpunkt erledigt sein wird. Nicht mehr, nicht weniger.

In manchen Organisationen arbeiten mehrere Teams parallel an einer Entwicklung. Denkbar wäre hier ein gemeinsames Diagramm für alle Teams, da jedoch Verzögerungen einzelner Teams nicht leicht zu erkennen wären, ist es vermutlich eine bessere Idee, pro Team ein Chart zu nutzen. Idealerweise sollte dies dann im Rahmen des Daily Scrums diskutiert werden.

“Das Fachwissen zu Softwarearchitekturen, die Expertise in der Softwareentwicklung und die sehr flexible Arbeitsweise waren ideal für uns.“

„Ihren Blog lese ich schon lange und mit großer Freude. Systematisch, auf den Punkt und ansprechend.“

Pin It on Pinterest

Share This