Startseite
Wissen kompakt
Burn-Down-Chart

Burn-Down-Chart

Inhaltsverzeichnis: Definition – Vorteile – Voraussetzungen – verschiedene Interpretationen – Kritik und Grenzen – Download – Hinweise

Wissen kompakt: Ein Burn-Down-Chart visualisiert Restaufwände in Relation zur verbleibenden Zeit in einem Scrum-Sprint bzw. einem definierten Zeitintervall.

Burn-Down-Chart Definition

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.

Burn-Down-Chart - Restaufwände reduzieren sich über die Zeit

Vorteile des Burn-Down-Charts

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.

Voraussetzungen für die Verwendung von Burn-Down-Charts

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. Story Points 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 lässt sich das Burn-Down-Chart interpretieren?

Werfen wir einen Blick auf verschiedene Beispiele:

Im ersten Beispiel sehen Sie einen idealen Verlauf, bei der eine proportionale Abnahme der Restaufwände im Zeitverlauf per gestrichelter Linie dargestellt wird. 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 (rote Markierung). Am Endes des Zeitintervalls ist der Restaufwand gleich null, alle Aufgaben sind also abgearbeitet (grüne Markierung). 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 blaue gepunktete Linie liegt unter der gestrichelten, die den durchschnittlichen bzw. proportionalen Verlauf anzeigt), dann war es ein wenig langsamer (die blauen Punkte befinden sich oberhalb der gestichelten Linie). Kurz vor Ende des Intervall lag das Team wieder vor dem Plan (die blauen Punkte befinden sich 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 (beginnend ab der roten Markierung). 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 gab (rote Markierung). 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 üblicherweise unangetastet.

Im Beispiel “Der Abbruch” ist nur 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 (immer an den roten Markierungen zu erkennen). 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.

Kritik und Grenzen des Burn-Down-Charts

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 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-, Burnup- oder Cumulative Flow 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.