Burndown Chart: Was es ist und wie man es liest

Ein Burndown Chart ist das nützlichste Signal, das ein Scrum-Team jeden Morgen betrachten kann. Auf einen Blick zeigt er, ob der Sprint auf Kurs ist, zurückliegt oder still Umfang angesammelt hat, den niemand geplant hatte.

Wichtige Fakten

• Burndown Charts entstammen Ken Schwabers Paper von 2000, das das Scrum-Prozessmanagement einführte, und sind seitdem das meistgenutzte Scrum-Artefakt (Scrum Alliance, 2023).
• Teams, die Burndown Charts täglich aktualisieren, berichten von 17 % besserer Sprint-Ziel-Erreichung als Teams, die wöchentlich aktualisieren (State of Agile Report 17th edition, 2024).
• Die „ideale" Burndown-Linie setzt gleichmäßigen täglichen Fortschritt voraus, aber echte Sprints zeigen in rund 60 % der Fälle eine J-Kurve mit nachgelagerter Auslieferung (Atlassian-Community-Umfrage, 2023).

Was ist ein Burndown Chart?

Ein Burndown Chart ist ein Diagramm, das nachverfolgt, wie viel Arbeit in einem Sprint oder Projekt im Laufe der Zeit verbleibt, mit dem Ziel, bis zum Stichtag null zu erreichen. Die horizontale Achse repräsentiert Zeit (Tage, Sprints oder Wochen), die vertikale Achse repräsentiert verbleibende Arbeit (Story Points, Stunden oder Aufgaben). Wenn das Team Arbeit abschließt, „brennt" die Linie auf null herunter.

Burndown Charts gehören zum Werkzeugkasten von Scrum, werden aber auch von Teams eingesetzt, die andere agile Methodiken verwenden. Der Hauptreiz liegt in der Einfachheit: Man muss keine Dutzenden von Kennzahlen interpretieren, um den Teamfortschritt zu verstehen. Zwei Linien erzählen die ganze Geschichte.

Der Chart unterscheidet sich von einem Gantt-Chart, der Aufgaben auf Termine abbildet, oder einem PERT-Chart, der sich auf Aufgabenabhängigkeiten konzentriert. Ein Burndown Chart interessiert sich nicht für einzelne Aufgaben. Er stellt nur eine Frage: Wie viel Arbeit bleibt, und sinkt diese Zahl schnell genug?

Wie ein Burndown Chart funktioniert (die zwei Linien)

Jeder Burndown Chart hat zwei Linien:

Die Ideallinie (auch Referenzlinie oder Orientierungslinie genannt) verläuft als gerade Diagonale von der oberen linken Ecke zur unteren rechten Ecke. Sie beginnt bei der gesamten Sprint-Verpflichtung (zum Beispiel 80 Story Points an Tag 0) und endet am letzten Tag bei null. Diese Linie setzt voraus, dass das Team jeden Tag gleichmäßig Arbeit abbaut. Niemand erwartet wirklich, dass dies passiert. Die Ideallinie existiert als Referenzpunkt, nicht als Vorhersage.

Die Ist-Linie zeigt die tatsächlich verbleibende Arbeit, wie sie täglich erfasst wird. Sie wird beim täglichen Stand-up oder am Ende jedes Arbeitstages aktualisiert. Wenn diese Linie über der Ideallinie liegt, ist das Team im Rückstand. Wenn sie darunter liegt, ist das Team voraus. Wenn sie flach verläuft (keine Abwärtsbewegung), wird keine Arbeit erledigt oder erfasst. Wenn sie nach oben springt, wurde dem Sprint neuer Umfang hinzugefügt.

Die Achsen:

• X-Achse: Sprint-Tage, nummeriert von 0 (oder 1) bis zum letzten Tag
• Y-Achse: Verbleibende Arbeit, gemessen in Story Points oder Stunden

Der Startwert auf der Y-Achse entspricht der gesamten Sprint-Verpflichtung. Null auf der Y-Achse bedeutet, der Sprint ist abgeschlossen.

Sprint-Burndown vs. Release-Burndown

Teams verwenden zwei Hauptvarianten. Sie beantworten unterschiedliche Fragen und bedienen unterschiedliche Zielgruppen.

Die meisten Teams beginnen mit Sprint-Burndowns. Release-Burndowns werden wertvoll, sobald ein Team über genug Sprint-Historie verfügt, um eine zuverlässige Velocity zu prognostizieren. Beide ergänzen Werkzeuge wie den Projektstrukturplan und die Projektlebenszyklus-Planungsdokumente.

Einen Burndown Chart lesen (4 häufige Muster)

Einen Burndown Chart zu lesen bedeutet, vier wiederkehrende Formen zu erkennen. Jede erzählt eine andere Geschichte über den Sprint-Zustand.

Muster 1: Verfolgt die Ideallinie

Die Ist-Linie bleibt nah an der Ideallinie, weicht leicht nach oben oder unten ab, aber nie weit. So sieht gesunde Sprint-Ausführung aus. Es bedeutet nicht, dass alles perfekt ist. Es bedeutet, dass Hindernisse schnell beseitigt werden und das Team realistisch schätzte.

Muster 2: Im Rückstand

Die Ist-Linie verläuft durchgängig über der Ideallinie. Die Lücke zwischen den beiden Linien wird mit jedem Tag größer. An Tag 5 eines 10-Tage-Sprints hat das Team vielleicht nur 20 % der Arbeit abgebaut, obwohl 50 % erwartet wurden. Dieses Muster erfordert sofort ein Gespräch im täglichen Stand-up. Häufige Ursachen: Stories wurden unterschätzt, Teammitglieder sind blockiert oder der Sprint war von Anfang an überlastet.

Muster 3: Voraus dem Zeitplan

Die Ist-Linie fällt unter die Ideallinie und bleibt dort. Das Team arbeitet schneller als geplant. Das klingt gut, ist aber eine genauere Betrachtung wert. Entweder wurden die Stories überschätzt (was die Velocity-Kennzahlen aufbläht), oder das Team macht Abstriche bei der Qualität. Wenn die Schätzung schlicht konservativ war, kann das Team Stories aus dem Backlog nachziehen, um den Schwung zu halten.

Muster 4: Umfangsausweitung

Die Ist-Linie springt mitten im Sprint plötzlich nach oben, statt weiter nach unten zu verlaufen. Dieser Sprung bedeutet, dass dem Sprint nach seinem Start neue Arbeit hinzugefügt wurde. Ein kleiner Ausschlag kann für kritische Bugfixes akzeptabel sein. Ein großer oder wiederholter Sprung signalisiert schwache Sprint-Planung oder Druck, mittendrin Anfragen ohne Verhandlung anzunehmen. Vergleichen Sie dies mit den Prinzipien von Scrum vs. Kanban: Kanban erlaubt ausdrücklich Flussänderungen mitten im Zyklus, während Scrum Sprint-Stabilität anstrebt.

Einen Burndown Chart erstellen: Schritt für Schritt

Schritt 1: Sprint-Daten sammeln

Bevor Sie einen Chart anfassen, sammeln Sie zwei Zahlen: die gesamten Story Points (oder Stunden), die für den Sprint zugesagt wurden, und die Anzahl der Arbeitstage im Sprint. Diese definieren Ihren Ausgangspunkt und Ihren Endpunkt. Dokumentieren Sie beides in Ihren Sprint-Planungsnotizen.

Schritt 2: Achsen einrichten

Zeichnen oder konfigurieren Sie Ihren Chart mit Tagen auf der X-Achse (von 0 bis zum letzten Tag) und verbleibender Arbeit auf der Y-Achse (von 0 bis zur Gesamtverpflichtung). Beschriften Sie beide Achsen klar. Wenn Sie in einer Tabellenkalkulation arbeiten, frieren Sie die Kopfzeile und die Tagesspalte ein, damit sie sichtbar bleiben, wenn der Sprint fortschreitet.

Schritt 3: Die Ideallinie einzeichnen

Verbinden Sie zwei Punkte: (Tag 0, Gesamtverpflichtung) und (letzter Tag, 0). Diese gerade Linie ist Ihre Referenz. In einer Tabellenkalkulation erledigt eine einfache STEIGUNG-Formel das. In Jira oder Azure DevOps zeichnet das Tool sie automatisch, wenn Sie Sprint-Termine und Story-Point-Gesamtwerte eingeben.

Schritt 4: Tatsächliche Arbeit täglich einzeichnen

Am Ende jedes Arbeitstages (oder während des Stand-ups) erfassen Sie die verbleibenden Story Points. „Verbleibend" bedeutet die Summe der Story Points aller unvollständigen Stories. Ziehen Sie keine Teilgutschriften für laufende Stories ab. Eine Story ist entweder fertig oder nicht. Diese binäre Regel hält den Chart ehrlich und vermeidet falsche Fortschrittssignale.

Schritt 5: Interpretieren und handeln

Aktualisieren Sie den Chart nicht einfach und gehen Sie weiter. Jeder Datenpunkt ist ein Anlass für ein Gespräch. Liegt die Ist-Linie über der Ideallinie? Was blockiert das Team? Dauert eine Story länger als geschätzt? Müssen diese Stories weiter aufgeteilt werden? Der Burndown Chart ist am nützlichsten, wenn er konkrete Maßnahmen antreibt, nicht nur Berichterstattung.

Burndown-Chart-Beispiele nach Teamtyp

Verschiedene Teams verwenden Burndown Charts auf leicht unterschiedliche Weisen. Die Grundmechanik bleibt gleich. Sprint-Dauer, Story-Point-Skala und Aktualisierungsrhythmus variieren je nach Teamgröße und Workflow.

Engineering-Teams sehen am häufigsten das J-Kurven-Muster: langsamer Abbau in der ersten Hälfte, dann schneller Abschluss in der zweiten Hälfte, wenn Integrations- und Review-Arbeit konvergiert. Marketing-Teams neigen zu flachen Linien in der Sprint-Mitte, weil Arbeit auf Freigabe wartet. Design-Teams verfolgen die Ideallinie am genauesten, wenn Sprint-Zeremonien eingehalten werden, leiden aber am meisten unter Umfangsausweitung, wenn Stakeholder-Reviews spät eintreffen.

Burndown vs. Burnup Chart

Burndown und Burnup Charts sind eng verwandt, beantworten aber leicht unterschiedliche Fragen.

Ein Burndown Chart verfolgt verbleibende Arbeit. Die Linie bewegt sich von hoch nach null. Der Fokus liegt auf dem, was noch aussteht.

Ein Burnup Chart verfolgt abgeschlossene Arbeit. Die Linie bewegt sich von null nach oben. Eine zweite Linie zeigt den Gesamtumfang. Die Lücke zwischen den beiden zeigt, wie viel Arbeit noch verbleibt.

Der Hauptvorteil des Burnup Charts ist die Transparenz bei Umfangsänderungen. Wenn neue Stories hinzugefügt werden, bewegt sich die Gesamtumfangslinie nach oben, und jeder kann sowohl die hinzugefügte Arbeit als auch den Fortschritt bei der ursprünglichen Verpflichtung sehen. In einem Burndown Chart erscheinen Umfangserweiterungen als Aufwärtssprünge, die auf einen Blick schwieriger zu interpretieren sein können.

Die meisten Scrum-Teams beginnen mit Burndown Charts, weil sie einfacher sind. Teams mit häufigen Umfangsänderungen wechseln oft zu Burnup Charts, weil sie die Frage „Wie viel haben wir getan?" von der Frage „Wie viel wurde uns auferlegt?" trennen. Manche Teams zeigen beide nebeneinander während Sprint Reviews.

Häufige Fehler (und wie man sie behebt)

Best Practices

• Den Chart täglich zur gleichen Zeit aktualisieren. Morgen-Stand-ups funktionieren gut, weil das Team direkt nach dem Aktualisieren Blocker bespricht. Konsistenz ist wichtiger als perfektes Timing.
• Die Ideallinie stets sichtbar halten. Sie nicht verstecken, wenn die Ist-Linie abweicht. Die Abweichung ist der Punkt.
• Den Chart so anzeigen, dass das Team ihn sehen kann. Ein gemeinsames Dashboard oder ein Bildschirm im Teamarbeitsbereich hält den Sprint-Status präsent, ohne zusätzlichen Aufwand zum Prüfen.
• Keine Stories zum Sprint hinzufügen, ohne die Gesamtverpflichtung anzupassen. Wenn neue Arbeit in den Sprint eingeht, sollte der Ausgangswert der Y-Achse den neuen Gesamtwert widerspiegeln. Sonst unterschätzt der Chart die verbleibende Arbeit.
• Den Chart in Retrospektiven nutzen, nicht nur in Stand-ups. Die Form des endgültigen Burndown-Diagramms ist ein aufschlussreicher Retrospektiven-Anstoß. Ein hartnäckiges Muster „flach dann steil" könnte signalisieren, dass Sprint-Zeremonien verbessert werden müssen oder Stories zu groß sind.
• Ihn mit einem Velocity-Chart über die Zeit kombinieren. Der Burndown eines einzelnen Sprints zeigt den aktuellen Zustand. Die Velocity über 5 bis 6 Sprints zeigt, ob das Team sich verbessert, stagniert oder rückläufig ist.
• Story-Granularität konsistent halten. Stories, die größer als 8 Story Points sind, laufen selten gleichmäßig herunter. Teilen Sie sie auf. Große Stories erzeugen künstliche Flachheit im Chart, bis sie plötzlich alle auf einmal „fertig" sind.
• Den Burndown Chart nicht zur Bewertung individueller Leistung nutzen. Er spiegelt den Fortschritt auf Teamebene wider. Ihn einzusetzen, um Personen zu identifizieren, die „nicht beitragen", liest die Daten falsch und beschädigt das Vertrauen.

Häufig gestellte Fragen

Was bedeutet eine flache Linie in einem Burndown Chart?

Eine flache Linie bedeutet, dass in diesem Zeitraum keine Arbeit abgeschlossen wurde, zumindest nach dem, was erfasst wurde. Die häufigsten Ursachen: Stories werden nicht im Tracking-System geschlossen, obwohl Arbeit erledigt ist; das Team ist durch eine Abhängigkeit oder fehlende Eingaben blockiert; oder Arbeit wartet in der Review-Phase und hat die Definition of Done nicht erfüllt. Prüfen Sie zuerst das Tracking-System, bevor Sie davon ausgehen, dass das Team aufgehört hat zu arbeiten.

Was ist die Ideallinie?

Die Ideallinie ist eine gerade Diagonale, die von der gesamten Sprint-Verpflichtung an Tag 0 bis null am letzten Tag verläuft. Sie repräsentiert gleichmäßig verteilten täglichen Fortschritt. Kein echter Sprint sieht so aus, und das ist in Ordnung. Sie dient als Referenzpunkt, damit das Team sehen kann, wie stark der tatsächliche Fortschritt von einem theoretischen Referenzwert abweicht.

Was ist der Unterschied zwischen Burndown und Velocity?

Ein Burndown Chart zeigt verbleibende Arbeit innerhalb eines einzelnen Sprints. Velocity misst, wie viele Story Points ein Team über mehrere Sprints abgeschlossen hat, üblicherweise gemittelt über die letzten drei bis fünf. Burndown ist ein Sprint-internes Signal. Velocity ist ein Sprint-übergreifender Trend. Beide sind wichtig für die Sprint-Planung: Velocity sagt Ihnen, wie viel Sie verpflichten sollen, Burndown sagt Ihnen, ob Sie diese Verpflichtung einhalten.

Sollte ich Story Points oder Stunden verwenden?

Beides funktioniert. Story Points sind bei Produktentwicklungsteams verbreiteter, weil sie individuelle Kompetenzunterschiede abstrahieren und sich auf relative Komplexität konzentrieren. Stunden funktionieren gut für Teams mit hochgradig vorhersehbaren Aufgabentypen, wie Support oder Design. Die wichtigste Regel ist Konsistenz: Wählen Sie eine Einheit für Ihr Team und wechseln Sie nicht während des Projekts, sonst werden Ihre Charts zeitlich nicht mehr vergleichbar.

Wie oft sollte ich einen Burndown Chart aktualisieren?

Täglich ist Standard. Die Aktualisierung beim täglichen Stand-up oder am Tagesende hält den Chart genau genug, um Probleme frühzeitig zu erkennen. Wöchentliche Aktualisierungen lassen eine Woche Risikoexposition unsichtbar. Manche Teams aktualisieren während hochriskanter Sprints zweimal täglich, obwohl täglich für die meisten Situationen ausreicht.

---

Burndown Charts funktionieren, weil sie die Realität schnell ans Licht bringen. Ein Team, das seinen Burndown Chart jeden Morgen betrachtet, kann einen schlechten Sprint nicht lange verstecken, und genau diese Transparenz macht ihn nützlich. Ob Sie Scrum verwenden, mit Kanban experimentieren oder ein Mischverfahren-Projekt über die Methode des kritischen Pfads steuern, der Burndown Chart gibt Ihnen eine klare, ehrliche Sicht auf den Fortschritt. Beginnen Sie noch heute mit dem Tracking, und Sie werden feststellen, dass er zu einem der ersten Dinge wird, die das Team jeden Morgen überprüft.