Burndown vs. Burnup – In agilen Projekten gehört der Blick aufs Board zum Alltag – doch viele Teams kämpfen damit, Fortschritt wirklich transparent zu machen. Burndown- und Burnup-Charts gelten als Standard, werden aber oft falsch verstanden oder nur halbherzig genutzt. Die Folge: Schönfärberei, Missverständnisse im Management und schlechte Entscheidungen.
Dieser Artikel erklärt praxisnah, worin sich Burndown vs. Burnup unterscheiden, wie Sie beide Diagrammtypen korrekt lesen, welche Fehler Sie vermeiden sollten und in welchen Situationen welches Chart deutlich im Vorteil ist. So schaffen Sie eine belastbare Datengrundlage für Steuerung, Prognosen und Stakeholder-Kommunikation.
Was ist ein Burndown Chart? – Kurz erklärt
Ein Burndown Chart zeigt, wie viel Arbeit in einem definierten Zeitraum noch übrig ist.
Auf der y-Achse steht der verbleibende Aufwand (z. B. Story Points, Stunden), auf der x-Achse die Zeit (z. B. Tage im Sprint).
Kernelemente eines Burndown Charts:
- Startpunkt: Gesamtaufwand zu Beginn (z. B. Sprintstart)
- Ideallinie: theoretisch gleichmäßiger Abbau der Arbeit
- Ist-Linie: tatsächlicher Fortschritt im Zeitverlauf
- Endpunkt: null verbleibender Aufwand = alles erledigt
Damit beantwortet das Burndown die Frage: „Wie viel Arbeit müssen wir noch erledigen, um rechtzeitig fertig zu werden?“
Was ist ein Burnup Chart? – Kurz erklärt
Ein Burnup Chart zeigt, wie viel Arbeit bereits erledigt wurde – und wie sich der Gesamtumfang entwickelt.
Auf der y-Achse stehen erledigter Aufwand und Gesamtumfang, auf der x-Achse die Zeit.
Kernelemente eines Burnup Charts:
- Linie „Scope“: aktueller Gesamtumfang (kann steigen oder fallen)
- Linie „Done“: kumuliert erledigte Arbeit
- Abstand zwischen beiden Linien: noch offene Arbeit
- Schnittpunkt: Zeitpunkt, an dem der erledigte Aufwand den Scope erreicht
Damit beantwortet das Burnup die Frage: „Wie entwickelt sich unser Fortschritt im Verhältnis zu einem sich verändernden Umfang?“
Burndown vs. Burnup: Der zentrale Unterschied
Der Kernunterschied:
- Burndown fokussiert auf die Restarbeit,
- Burnup auf die geleistete Arbeit im Kontext des Umfangs.
Die praktische Konsequenz:
- Im Burndown ist oft nicht sofort sichtbar, ob sich der Umfang verändert hat.
- Im Burnup erkennt man Scope-Änderungen direkt als Verschiebung der Umfangslinie.
Gerade in dynamischen Projekten mit häufigen Änderungen im Backlog ist das Burnup daher oft die aussagekräftigere Wahl.
Wie liest man ein Burndown Chart richtig?
Achsen und Linien verstehen
- X-Achse (Zeit): Sprinttage, Iterationen oder Kalendertage.
- Y-Achse (Aufwand): z. B. Story Points, Tickets, Personentage.
- Ideallinie: „Leitplanke“ für einen gleichmäßigen Abbau.
- Ist-Linie: realer Verlauf, meist zackig, da Arbeit oft in Blöcken fertig wird.
Typische Muster im Burndown
1. „Wasserfall“-Muster (lange flach, dann steiler Absturz)
- Deutet oft auf „alles am Ende fertig“ hin
- Risiko: späte Erkenntnis, wenn etwas nicht klappt
- Mögliche Ursache: Arbeiten werden erst spät abgenommen oder zerlegt
2. Stagnation über mehrere Tage
- Kaum Tickets werden „Done“
- Mögliche Ursachen:
- Blocker, Abhängigkeiten, fehlende Entscheidungen
- Zu große User Stories, mangelnde Zerlegung
- Team ist mit Nebenarbeit beschäftigt, die nicht im Sprint Backlog steckt
3. Unter der Ideallinie
- Team ist dem Plan voraus
- Vorsicht: Prüfen, ob Definition of Done wirklich eingehalten wird
4. Über der Ideallinie
- Verzug gegenüber dem Plan
- Erfordert Transparenz: Was hindert das Team, was muss geklärt werden?
Wie liest man ein Burnup Chart richtig?
Aufbau des Burnup
- Linie „Scope“ (Gesamtumfang)
- Zeigt die aktuelle Gesamtmenge der geplanten Arbeit
- Steigt bei neuen Anforderungen, sinkt bei Scope-Reduktion
- Linie „Done“ (erledigt)
- Kumulierte Summe der fertiggestellten Arbeit
- Steigt mit jeder abgeschlossenen User Story oder jedem Ticket
Typische Muster im Burnup
1. Done-Linie steigt, Scope bleibt stabil
- Klassischer, gut „kontrollierter“ Verlauf
- Fortschritt ist klar und Prognosen sind relativ stabil
2. Done-Linie steigt, Scope steigt ebenfalls
- Team liefert, aber die Anforderungen wachsen
- Aussage: „Wir arbeiten konstant, aber das Ziel entfernt sich.“
3. Kaum Anstieg der Done-Linie
- Ähnlich wie beim Burndown: Blocker, falscher Fokus oder Überlastung
- Im Burnup ist zugleich sichtbar, ob parallel der Umfang erhöht wurde
4. Umfang sinkt
- Scope wird reduziert, z. B. durch Priorisierung
- Ermöglicht bewusste Entscheidungen: „Wir streichen Features, um den Termin zu halten.“
Vor- und Nachteile: Burndown Chart
Vorteile des Burndown
- Einfach zu verstehen für Einsteiger
- Gut geeignet für kurze, klar abgegrenzte Sprints
- Schneller Blick: „Sind wir im Sprint im Plan?“
Nachteile des Burndown
- Scope-Änderungen sind schwer erkennbar
- Wenn während des Sprints Arbeit hinzugefügt oder entfernt wird, verschiebt sich die Startmenge – die Visualisierung kann irreführend werden.
- Gefahr der Fehlinterpretation:
- Ein schlechtes Burndown kann als „Team arbeitet nicht“ gelesen werden, obwohl eigentlich der Umfang gestiegen ist.
- Fokussiert stark auf „Restarbeit“ statt auf „geleistete Leistung“
- Für Management und Stakeholder ist die positive Sicht („Was ist geschafft?“) oft hilfreicher.
Vor- und Nachteile: Burnup Chart
Vorteile des Burnup
- Transparenz bei Scope-Änderungen
- Umfangsänderungen werden explizit als Verschiebung der Scope-Linie sichtbar.
- Gute Basis für Prognosen
- Aus der Steigung der Done-Linie kann man die durchschnittliche Liefergeschwindigkeit (Velocity) ableiten.
- Stärkerer Fokus auf Wertschöpfung
- Diskussion dreht sich mehr um „Was haben wir geliefert?“ als um „Wie viel fehlt noch?“.
- Besser geeignet für länger laufende Initiativen und Produkte mit sich entwickelnden Backlogs.
Nachteile des Burnup
- Für Einsteiger visuell etwas komplexer als ein Burndown
- Erfordert saubere Pflege des Scope (inkl. Dokumentation von Änderungen)
- Wenn mehrere Teams an einem gemeinsamen Scope arbeiten, muss die Aggregation klar geregelt sein
Burndown vs. Burnup: Wann eignet sich welches Diagramm?
Burndown ist besonders sinnvoll, wenn …
- Sie kurze Sprints mit stabiler Planung fahren
- der Umfang während des Sprints nur in Ausnahmefällen geändert wird
- Sie eine einfache Darstellung für das tägliche Stand-up benötigen
- das Team erst mit Visualisierung beginnt und Komplexität gering halten möchte
Burnup ist besonders sinnvoll, wenn …
- Sie längerfristige Produktentwicklungen oder Programme steuern
- laufend neue Anforderungen entstehen oder Prioritäten sich verändern
- Management und Stakeholder Scope-Änderungen klar nachvollziehen sollen
- Sie seriöse Forecasts auf Basis von Velocity und Trends erstellen wollen
Praxisempfehlung
Viele Organisationen nutzen:
- Burndown: für die Sprint-Sicht im Team
- Burnup: für die übergeordnete Produkt- und Release-Sicht im Management
So kombinieren Sie operative Transparenz mit strategischer Steuerung.
Wichtige W‑Fragen zu Burndown und Burnup
Warum überhaupt Burndown oder Burnup nutzen?
Weil beide Diagrammtypen helfen, typische Blindspots zu vermeiden:
- Unrealistische „Gefühlsprognosen“ („Wir schaffen das schon irgendwie“)
- Überraschungen am Ende des Sprints oder Releases
- Diskussionen ohne gemeinsame Datengrundlage
Wer sollte die Charts nutzen?
- Product Owner / Product Manager: für Priorisierung und Stakeholder-Dialog
- Scrum Master / Agile Coaches: für kontinuierliche Verbesserung
- Teammitglieder: für tägliche Selbststeuerung
- Führungskräfte: für Statusberichte und Portfolio-Entscheidungen
Wie oft sollte man auf die Charts schauen?
- Im Daily: kurzer Blick auf das aktuelle Sprint-Burndown
- In Review/Review-ähnlichen Terminen: Blick auf Burnup/Release-Sicht
- In Steuerungsrunden / Management-Meetings: Burnup als Grundlage für Entscheidungen
Burndown vs. Burnup in Scrum, Kanban und hybriden Setups
In Scrum
- Sprints haben einen klaren Zeithorizont, daher:
- Sprint-Burndown: Fortschritt innerhalb eines Sprints
- Release-Burnup: Fortschritt über mehrere Sprints hinweg
So wird die kurzfristige Sprintplanung mit der längerfristigen Roadmap verbunden.
In Kanban
- Kanban arbeitet eher flussorientiert ohne feste Sprints.
- Hier ist ein Burnup meist hilfreicher, etwa für:
- Messung von Durchsatz (Throughput)
- Visualisierung, wie sich Umfang und Liefermenge über Zeit entwickeln
Ein klassisches Burndown passt weniger gut zu kontinuierlichem Flow ohne Sprintgrenzen.
In hybriden Modellen (z. B. SAFe, LeSS, Projekt + Produktmix)
- Burndown auf Team- oder Iterationsebene
- Burnup für:
- Program Increment (PI)-Planung
- Gesamtprojekt-Fortschritt
- Multiprojekt- oder Portfolio-Sicht
Typische Fehler im Umgang mit Burndown und Burnup
1. Charts als „Kontrollinstrument“ statt Lerninstrument nutzen
- Nur auf „rote“ Verläufe zu schauen und Druck zu erhöhen, führt zu:
- Schönfärben von Daten
- Widerstand im Team
- Besser: Diagramme als Ausgangspunkt für Ursachenanalyse und Verbesserungen verwenden.
2. Unklare Definition of Done
- Wenn „Done“ unterschiedlich interpretiert wird, sind Charts wertlos.
- Stellen Sie sicher:
- Gemeinsame, dokumentierte Definition of Done
- Strenge Anwendung im gesamten Team
3. Scope-Änderungen nicht sauber pflegen
- Arbeitsumfang wird nachträglich verändert, ohne ihn zu dokumentieren.
- Besonders kritisch im Burndown, aber auch im Burnup.
- Empfehlung:
- Scope-Änderungen explizit festhalten
- Im Burnup sichtbar machen
- Im Sprint-Burndown zumindest im Daily ansprechen
4. Zu grobe User Stories
- Wenige große Stories führen zu:
- Flachem Verlauf, dann plötzlichem Absturz
- Schlechter Aussagekraft der Diagramme
- Lösung:
- Stories in kleinteiligere, klar abgrenzbare Arbeitseinheiten zerlegen
5. Fehlende Verknüpfung mit Entscheidungen
- Charts werden zwar erzeugt, aber:
- Niemand leitet Maßnahmen ab
- Keine Anpassung von Scope, Prioritäten oder Arbeitsweise
- Achten Sie darauf, aus Mustern konkrete Schritte abzuleiten.
Aufwandseinheiten: Story Points, Stunden oder Tickets?
Story Points
- Häufigste Einheit in Scrum-Teams
- Abstrakte Größe (Komplexität, Risiko, Umfang)
- Gut geeignet, um Velocity und Trends im Burnup zu analysieren
Stunden oder Personentage
- Wirken für Management oft intuitiver
- Gefahr: Rückfall in Mikromanagement und Scheinpräzision
- Eher für Teams sinnvoll, die noch stark in klassischem Projektcontrolling verankert sind
Anzahl Tickets
- Einfachste Zähleinheit
- Funktioniert gut, wenn Tickets relativ homogen und klein sind
- Für sehr unterschiedliche Ticketgrößen weniger aussagekräftig
Empfehlung:
Für agile Produktentwicklung in stabilen Teams sind Story Points plus Burnup eine bewährte Kombination. In eher klassischen Projektumgebungen kann ein stundenbasiertes Burndown als Einstieg helfen.
Schritt-für-Schritt: Einführung von Burndown und Burnup in Ihrem Team
- Ziel klären
- Was wollen Sie mit den Diagrammen erreichen?
- Z. B. bessere Sprint-Prognosen, transparentere Scope-Änderungen, fundiertere Management-Entscheidungen.
- Einheit wählen
- Story Points, Stunden oder Tickets – bewusst entscheiden, nicht zufällig.
- Definition of Done festlegen oder schärfen
- Einigkeit herstellen, wann eine Arbeitseinheit wirklich „Done“ ist.
- Tooling aufsetzen
- In vielen Tools (z. B. Jira, Azure DevOps, Trello-Erweiterungen) lassen sich Burndown und Burnup automatisiert erzeugen.
- Wichtig: Konfiguration prüfen, damit die Diagramme die Realität widerspiegeln.
- Regelmäßige Nutzung verankern
- Burndown: fester Bestandteil im Daily (max. 2–3 Minuten).
- Burnup: Bestandteil von Review, Planning, Steuerungsgremien.
- Gemeinsame Interpretation einüben
- Im Team und mit Stakeholdern regelmäßig besprechen:
- Was sehen wir?
- Was bedeutet das?
- Welche Anpassungen folgen daraus?
- Im Team und mit Stakeholdern regelmäßig besprechen:
- Feedback einholen und nachjustieren
- Sind die Diagramme hilfreich?
- Müssen Einheiten, Granularität oder Meeting-Strukturen angepasst werden?
Burndown vs. Burnup: Welche Fragen beantwortet welches Chart besser?
Burndown beantwortet vor allem:
- Wie viel Arbeit ist im Sprint noch offen?
- Sind wir innerhalb dieses Sprints im Plan?
- Müssen wir kurzfristig umpriorisieren, um das Sprintziel zu erreichen?
Burnup beantwortet vor allem:
- Wie viel haben wir bereits geliefert?
- Wie verändert sich der Gesamtumfang über die Zeit?
- Wann können wir voraussichtlich ein Release oder Zielpaket abschließen, wenn wir mit der aktuellen Geschwindigkeit weitermachen?
- Welche Auswirkungen haben neue Anforderungen auf unsere Liefertermine?
Wenn Sie sich zwischen Burndown vs. Burnup entscheiden müssen, sollten diese Fragen den Ausschlag geben. Für die meisten professionellen Umgebungen lohnt sich jedoch der kombinierte Einsatz.
Fazit: Burndown vs. Burnup bewusst kombinieren
Burndown- und Burnup-Charts sind keine Selbstzweck-Grafiken, sondern Werkzeuge für bessere Entscheidungen.
- Nutzen Sie das Burndown, um in überschaubaren Sprints die tägliche Arbeit zu steuern.
- Nutzen Sie das Burnup, um übergreifend Transparenz über Fortschritt, Scope-Änderungen und realistische Liefertermine zu schaffen.
Entscheidend ist nicht das „perfekte“ Diagramm, sondern ein gemeinsames Verständnis im Team und mit Stakeholdern, was die Daten bedeuten – und welche Konsequenzen Sie daraus ziehen.
Wenn Sie Unterstützung bei der Einführung einer belastbaren Fortschrittsmessung, beim Aufsetzen sinnvoller Burndown- und Burnup-Charts oder bei der agilen Skalierung in komplexen Organisationen wünschen, kann eine externe Perspektive helfen. Die Beraterinnen und Berater von PURE Consultant begleiten Sie dabei, passende Metriken und Visualisierungen für Ihre konkrete Situation zu definieren und nachhaltig in Ihrer Organisation zu verankern.