Was ist ein Burndown Chart?

Burn Down Chart. Sprints mit dem Restaufwand überwachen.

Was zeigt ein Burn Down Chart? Welche Vorteile bietet es und wie erstellen Sie Burn Down Charts?

tooltip text
1

Das Burn Down Chart ist ein Kontrollmittel für Sprints in agilen Projekten (z.B. Scrum-Projekten). Es visualisiert die noch zu leistende Arbeit im Verhältnis zur Zeit und gibt Ausschluss darüber, ob Sie das geplante Ziel erreichen können. Basierend auf den Verlauf der Linien können Sie auch feststellen, ob die Entwicklung über- oder unterfordert ist.

2

Einen idealen Verlauf des Restaufwands werden Sie in der Praxis niemals sehen. Stattdessen schwankt diese Linie. Wenn sie weit oberhalb des Ideals liegt, dann könnten womöglich zu viele Anforderungen für den Sprint eingeplant sein.

3

Liegt die Linie des Restaufwands unter die Ideallinie, so arbeiten die Entwickler sehr schnell und sind möglicherweise unterfordert.

Was ist das Burn Down Chart?

Wie viel Arbeit steht im aktuellen Sprint noch an? Liegen Sie im Plan oder arbeiten Sie zu langsam? Fragen, die Ihnen häufig in agilen Scrum-Projekten begegnen. Um diese Fragen zu beantworten, hat sich das sogenannte Burn Down Chart bewährt: Es visualisiert, wie viel Arbeit Sie zum aktuellen Zeitpunkt noch erledigen müssen. Außerdem lässt sich anhand des Diagramms erschließen, wie schnell das Team arbeitet. Darauf basierend können Sie zum Beispiel feststellen, ob die Entwickler zu viele oder zu wenige Aufgaben zur Bearbeitung erhalten haben, und diese Erkenntnis für die nächste Planphase einbeziehen. Das Burn Down Chart eignet sich, um Iterationen bzw. Sprints zu kontrollieren. Denn dort ist der Scope – d.h. die Anzahl der umzusetzenden Anforderungen – in einer definierten Zeitspanne fixiert.

Mehr über Scrum »

Vorteile des Burn Down Chart

  • Einfach verständliches Hilfsmittel für das Sprintcontrolling
  • Schnelle Übersicht über noch zu leistende Arbeit in einer Iteration
  • Realistische Aussagen, da durch das Entwicklungsteam täglich gepflegt
  • Indikator, ob sich das Entwicklungsteam im Zeitplan befindet
  • Indikator für Schnelligkeit und Schätzfähigkeit des Teams
  • Mittel zur Risikoerkennung durch tägliche Aktualisierung
  • Mittel zur Kommunikation mit Kunden und Stakeholdern

Kurze Definition des Burn Down Chart:

Das Burn Down Chart ist ein Kontrollmittel für Sprints in agilen Projekten (z.B. Scrum-Projekten). Es visualisiert die noch zu leistende Arbeit zu einem Stichtag und gibt Ausschluss darüber, ob das Entwicklungsteam das geplante Ziel erreichen kann.

Wie erstellen Sie ein Burn Down Chart?

Das Burn Down Chart stützt sich auf Tasks und darauf, dass die Entwickler jeden Tag den Restaufwand für ihre Implementierung schätzen. Daher müssen Sie als ersten Schritt Ihre User Storys in Tasks herunterbrechen und ihre Aufwände schätzen.

Als nächsten Schritt erstellen Sie das Diagramm. Ein Burn Down Chart besteht immer aus einer x- Achse mit der Zeit und eine y-Achse mit dem Restaufwand. Da Sie den Restaufwand der Tasks täglich erfassen, sehen Sie auf der x-Achse eine Messung in Tage. Für den Restaufwand eignet sich zum Beispiel eine Angabe in Story Points oder Stunden.

In der simpelsten Form zeigt Ihnen das Burn Down Chart nur eine Kurve für die täglich erfassten Restaufwände. Um den Idealverlauf des Sprints zu visualisieren, zeichnet man häufig eine zweite, linear verlaufende Kurve ein.

Da Sie den Restaufwand im Sprint verfolgen, beginnen die Kurven nicht bei 0, sondern beim Wert des Gesamtaufwands zu Anfang der Iteration, zum Beispiel bei 50 Stunden. Sie tragen dann jeden Tag den geschätzten Restaufwand für die Tasks ein. Am Ende des Sprints soll der Restaufwand den Wert 0 erreichen – die Anforderungen wurden umgesetzt. Daher fällt das Diagramm im Verlauf des Projekts nach unten und zeigt gleichzeitig, wie viel Arbeit noch zu „verbrennen“ ist (und daher der Name “Burn down” Chart).

Voraussetzungen für ein Burn Down Chart

Die Größe und der Detailgrad der Tasks müssen angemessen sein:

Der Umfang der Tasks sollte nicht zu groß sein, damit Entwickler den Restaufwand realistisch schätzen können. Daher müssen Sie Ihre User Storys in einer geeigneten Anzahl an Tasks herunterbrechen. In großen Scrum-Projekten führt dies zu einer hohen Menge an Anforderungen, die verwaltet werden müssen. Um diese Herausforderung zu bewältigen, setzen Sie am besten eine Software ein.

Der Restaufwand ist nicht der bereits erbrachte Aufwand:

Sie müssen jeden Tag den Restaufwand eines Task neu schätzen. Wenn Sie zum Beispiel am Mittwoch feststellen, dass der Aufwand doch noch größer ist, als am Montag geschätzt, dann geben Sie diesen höheren Restaufwand an. Wie viel Aufwand Sie bereits erbracht haben, spielt für die Restaufwandsschätzung im Burn Down Chart keine Rolle.

Der Restaufwand muss täglich erfasst werden:

Das Burn Down Chart fordert von den Entwicklern, ihren Restaufwand täglich am Ende des Arbeitstages zu schätzen. Dementsprechend müssen diese diszipliniert dieser Aufgabe nachgehen, damit das Burn Down Chart den tatsächlichen Stand im Sprint wiedergibt.

 

Beispiel für ein Burn Down Chart

Beispiel Burndown Chart in in-STEP BLUE

 In diesem Beispiel sehen Sie, dass

  • der Sprint eine Länge von 5 Tagen hat (siehe x-Achse mit der Zeitangabe)
  • und der Aufwand der Tasks zu Anfang des Sprints 30 Stunden entspricht.

Der Idealaufwand ist die graue, linear verlaufende Kurve. Die blaue Linie ist der Restaufwand. Was können Sie von diesem Burn Down Chart ablesen?

An Tag 1 entspricht der Restaufwand noch 30 Stunden. Die Entwickler haben höchstwahrscheinlich an ihren Tasks gearbeitet, aber schätzen am Ende des Arbeitstages, dass sie noch genau so viel Aufwand wie am Morgen haben werden.

An Tag 2 wird der Restaufwand geringer geschätzt. Sie können sehen, wie der Restaufwand noch 27,5 Stunden beträgt.

Am dritten Tag geben die Entwickler eine positivere Prognose: Der Restaufwand fällt um 10 Stunden auf 17,5 Stunden

Was passiert aber an Tag 4 und 5? Plötzlich sieht es nach Stillstand aus, so, als hätte niemand mehr gearbeitet. Ist das tatsächlich der Fall oder gibt es andere Gründe? Wie auch beim Cumulative Flow Diagram kann es verschiedene Ursachen für diese Entwicklung geben – und Sie müssen diesen Gründen auf die Spur kommen.

Mehr über das Cumulative Flow Diagram »

So arbeiten Sie mit Burndown Charts in der Praxis

Erfahren Sie hier mehr zu Agilität mit objectiF RPM »

objectiF RPM

Interpretation des Burn Down Chart

Wenn Sie ein Burn Down Chart interpretieren, lautet die erste Regel: Es gibt niemals eine ideal verlaufende Linie für den Restaufwand. Punkt. Wenn Sie solch eine Entwicklung sehen, dann müssen Sie die Glaubwürdigkeit dieses Diagramms hinterfragen. Höchstwahrscheinlich lautete dort das Motto: Ich gebe an, was erwartet wird und nicht, was der Realität entspricht. Neben diesen (hoffentlich) nicht auftretenden Fall, gibt es aber auch weitere Möglichkeiten für den Verlauf der Kurven, aus denen sich Rückschlüsse ziehen lassen. Zum Beispiel:

Fall 1: Das Team konnte nicht alle Tasks im Sprint umsetzen

Der Restaufwand am Ende des Sprints erreicht nicht 0: Die Entwickler konnten also nicht alle Anforderungen umsetzen. Die Gründe für diese Entwicklung können variieren: Zum Beispiel arbeiteten die Entwickler einfach zu langsam oder sie waren mit der Anzahl der Tasks im Sprint überfordert. Die Ursache müssen Sie herausfinden, damit Sie den nächsten Sprint besser planen können.

Fall 2: Das Team eilt am Ende des Sprints, um alle Tasks umzusetzen

Die Kurve des Restaufwands sinkt eine Zeit lang nur schwach oder verläuft sogar fast horizontal und dann plötzlich fällt sie herab und erreicht einen Restaufwand von 0. Am Ende des Sprints haben die Entwickler also Vollgas gegeben, um alle Anforderungen umzusetzen. Aber warum verlief die Arbeit erst so träge? Waren die Entwickler vielleicht unterfordert und haben die Aufgaben hingeschoben, bis sie sich sputen mussten? Hier könnte auch der Fall greifen, dass die Tasks zu groß bemessen worden sind und sich der Fortschritt dadurch schwer verfolgen ließ. Diesen Fragen sollten Sie dann nachgehen.

Burn Down Chart vs. Burn Up Chart

Das Burn Down Chart eignet sich dort, wo es einen fixierten Umfang der Anforderungen gibt. Wenn Sie das Diagramm für das gesamte Projekt mit allen Releases und Sprints einsetzen wollen, stößt es an seine Grenzen. Zum Beispiel sehen Sie dort ebenfalls eine gerade verlaufende Linie oder gar eine steigende Linie des Restaufwands. In diesen Fällen kann es noch einen weiteren Grund für diese Entwicklung geben: Es sind neue Anforderungen hinzugekommen – der Scope hat sich also geändert. Das ist nicht unüblich im täglichen Geschäft eines Scrum-Projekts. Da sich die Menge an Anforderungen im Verlauf eines agilen Projekts immer ändert und das Burn Down Diagram diesen Umstand nicht berücksichtigt, eignen sich als Controlling-Werkzeuge für das gesamte Projekt andere Diagramme wie das Burn Up Chart oder das Cumulative Flow Diagram.

Überwachen Sie Ihre Sprints

Wenn Sie agil sind und mit Timboxing à la Scrum arbeiten, müssen Sie immer wissen, wie Ihr Sprint aktuell verläuft. Aber auch Ihre Stakeholder interessiert das natürlich brennend. Mit einem Burn Down Chart können Sie schnell erfassen, wie viel Arbeit noch zu erledigen ist und ob sich das Ziel des Sprints erreichen lässt. Da Sie den Restaufwand der Tasks täglich erfassen, können Sie ebenfalls auf einen Blick erkennen, ob der Sprint gefährdet ist. Aber wollen Sie das Diagramm per Hand zeichnen? Oder ein Werkzeug zur Planung Ihrer Sprints nutzen und ein anderes, um sie als Burn Down Charts zu visualisieren? Setzen Sie eine Software ein, die Ihnen ein Vorlage für Scrum-Projekte bietet, mit der Sie Sprints, User Storys und Tasks anlegen und Auswertungen wie zum Beispiel durch ein Burn Down Chart anfertigen können.