Burn-Down-Charts sind eine beliebte Methode der agilen Produktentwicklung. Für agile Teams existieren dabei zwei grundsätzliche Anwendungsfälle. Und zwar einerseits als Sprint Burn-Down-Chart, das die Entwickler des Teams in ihrer Selbstorganisation unterstützt. Und andererseits als Release Burn-Down-Chart, das den Product Owner dabei unterstützt, gegenüber seinen Stakeholdern auskunftsfähig zu sein.
In dieser Anleitung stelle ich Dir beide Anwendungsfälle detailliert vor und zeige Dir, wie Du Burn-Down-Charts in Deinem Scrum Team noch besser einsetzen kannst.
- Aufbau eines Burn-Down-Charts
- Das Sprint Burn-Down-Chart
- Sprint Burn-Down-Charts mit Zeitaufwänden
- Sprint Burn-Down-Chart mit Story Points
- Das Release Burn-Down-Chart
- Mit dem Release Burn-Down-Chart Vorhersagen treffen
- Scope-Veränderungen auf dem Release Burn-Down-Chart abbilden
- Alternativen zu Burn-Down-Charts
- Fazit zu Burn-Down-Charts
Aufbau eines Burn-Down-Charts
Der grundsätzliche Aufbau eines Burn-Down-Charts ist sehr simpel. Es besteht aus einem Koordinatensystem, das den verbleibenden Aufwand und den zeitliche Verlauf visualisiert.
Wie genau Aufwand und Zeit dabei erfasst werden, ist für die Funktion des Burn-Down-Charts erst einmal zweitrangig.
Je nachdem, ob es sich um ein Sprint oder Release Burn-Down-Chart handelt, werden beide Metriken unterschiedlich genutzt.
Idealtrend & verbleibender Aufwand
Wichtig ist vielmehr, dass der verbleibende Aufwand (spätestens) zu definierten Zeitpunkten aktualisiert wird.
Zu besseren Visualisierung bietet es sich an, das Burn-Down-Chart mit einer Ideallinie zu versehen.
Die fortlaufende Visualisierung des aktuellen Aufwands im Vergleich zur Ideallinie hilft Euch dabei, möglichst gut einschätzen zu können, ob zum definierten Ende (Deadline) auch wirklich alles fertig ist.
Burn-Down-Chart mit Trendlinie
Falls Ihr Euch noch mehr Transparenz wünscht, könnt Ihr Euer Burn-Down-Chart noch um eine sogenannte Trendlinie ergänzen.
Die Trendlinie visualisiert damit den tatsächlichen (durchschnittlichen) Aufwand, den Ihr bisher abgearbeitet habt. Durch sie könnt Ihr daher leichter einschätzen, wo Ihr (höchstwahrscheinlich) am Ende rauskommt. Liegt die Trendlinie über der Ideallinie, werdet Ihr Euer Ziel höchstwahrscheinlich verfehlen. Liegt sie darunter, werdet Ihr eventuell früher fertig sein.
Hier siehst Du ein Sprint Burn-Down-Chart mit einer Trendlinie, die auf dem Stand des fünften Tages einer Iteration basiert. Wenn dieses Team nichts unternimmt, kann es davon ausgehen, sein Sprintziel nicht zu erreichen, weil die Trendlinie deutlich über der Ideallinie liegt.
Das Sprint Burn-Down-Chart
Einer der Hauptgründe, die für die Nutzung eines Sprint Burn-Down-Charts sprechen, ist die Selbstorganisation eines Scrum Teams. Denn der optimale Fall sieht ja so aus, dass sich Entwickler, Scrum Master und Product Owner im Sprint Planning auf ein gemeinsames Sprintziel geeinigt und einen Plan entwickelt haben, um dieses Ziel zu erreichen. Und dieser Plan ist im Grunde nichts anderes als das Sprint Backlog:
Das Sprint Backlog ist ein Plan von und für die Entwickler. Es ist ein deutlich sichtbares Echtzeitbild der Arbeit, welche die Entwickler während des Sprints zur Erreichung des Sprintziels ausführen wollen. Folglich wird das Sprint Backlog während des gesamten Sprints immer dann aktualisiert, wenn mehr gelernt wurde. Es sollte genügend Details beinhalten, damit sie ihren Fortschritt im Daily Scrum überprüfen können.
Eine einfache To-Do-Liste oder ein Kanban Board als Sprint Backlog sind zu diesem Zweck jedoch oft nur bedingt hilfreich. Deshalb hat sich bei den meisten Scrum Teams die Nutzung eines Sprint Burn-Down-Charts etabliert, um das oben erwähnte Echtzeitbild zu ermöglichen. (Auch wenn es kein fester Bestandteil des Scrum Frameworks ist.) Wenn Du so möchtest, ist das Sprint Burn-Down-Chart eine zusätzliche (und sehr hilfreiche) Visualisierung Eures Sprint Backlogs.
Sprint Burn-Down-Charts mit Zeitaufwänden
Viele Scrum Teams schätzen die notwendigen Stunden für die zu erledigenden Aufgaben (Tasks) ihres Sprints und visualisieren diese dann als zeitlichen Aufwand auf ihrem Sprint Burn-Down-Chart. Dieses Vorgehen hat einige Vor- als auch Nachteile, auf die ich ein wenig genauer eingehen möchte.
Zunächst einmal muss sich Dein Team gemeinsam darüber Gedanken machen, wie viele Stunden pro Tag es für die tatsächliche Arbeit am Produkt aufwenden kann. Wenn Ihr beispielsweise zu dem Schluss kommt, insgesamt 5 Stunden pro Tag für die Arbeit am Sprint aufzuwenden und Dein Team aus insgesamt 6 Entwicklern besteht, kommt Ihr damit auf eine Kapazität von insgesamt 270 Stunden bei einem 14-tägigem Sprint. (5 Stunden × 9 Arbeitstage × 6 Entwickler)
Während des Sprints werden dann die verbleibenden Stunden Eurer Aufgaben bzw. User Stories aktualisiert, sodass Ihr (im Vergleich mit der Ideallinie) erkennen könnt, wo Ihr aktuell steht.
Wichtig: Ihr müsst darauf achten, dass Ihr den verbleibenden Aufwand trackt. (Und nicht, wie viele Stunden Ihr abgearbeitet habt.)
Wenn Du mit Deinem Team ein Sprint Burn-Down-Chart mit Zeitaufwänden nutzen möchtest, müsst Ihr natürlich für jede Aufgabe eine Stundenschätzung festhalten.
Das kann durchaus hilfreich sein, weil Ihr so bereits im Sprint Planning erkennen könnt, ob Ihr Euch vielleicht zu viel vornehmt. (Oder ob Ihr noch „Luft nach oben“ habt.)
Gleichzeitig erzeugt diese Art des Sprint Plannings natürlich auch viel Aufwand.
So müsst Ihr beispielsweise bereits im Planning festhalten, ob 2 oder sogar 3 Entwickler gemeinsam an einer Aufgabe arbeiten wollen und das mit einer Erhöhung der dazugehörigen Stunden für diesen Tasks notieren. (Ein Task, an dem 3 Entwickler jeweils 5 Stunden arbeiten, hat daher 15 Stunden Aufwand.)
Vorteile eines Sprint Burn-Down-Charts mit Zeitaufwänden
Einen Vorteil dieser Art von Burn-Down-Chart habe ich bereits oben genannt. Durch das Schätzen von Zeitaufwänden könnt Ihr in Eurem Team recht früh erkennen, ob Ihr Euch nicht doch eventuell zu viel (oder zu wenig) vornehmt. Es gibt aber noch weitere Vorteile.
Die verbleibende Kapazität kann visualisiert werden
Wenn Ihr in Eurem Team die Kapazitäten beim Planning ermittelt und auch Urlaubstage etc. festhaltet, dann ergibt sich dadurch eine weitere Linie, die auf dem Sprint Burn-Down-Chart angezeigt werden kann.
Hier siehst Du beispielsweise ein Team, bei dem am sechsten Tag eines Sprints vier von fünf Entwicklern nicht am Sprint arbeiten können.
Dadurch ergibt sich auf dem Burn-Down-Chart ein sichtbarer Knick in der dunkelrote Linie, die die Kapazität dieses Scrum Teams visualisiert.
Diese Visualisierung kann für Teams, bei denen Entwickler aus diversen Gründen häufig abwesend sind, sehr viel hilfreicher sein als die Idealtrend-Linie!
Nutzung des On Product Index
Die Nutzung von Stunden beziehungsweise Zeit für ein Sprint Burn-Down-Chart hat noch einen weiteren Vorteil. Und zwar lernt Dein Team nach und nach, wie viel Zeit es tatsächlich für die Arbeit am Produkt aufwenden kann. Es gibt sehr viele Teams, die anfänglich davon ausgehen, 6 Stunden pro Tag an ihrem Produkt arbeiten zu können. Durch eine Auswertung vergangener Sprints können sie aber klar erkennen, dass es tatsächlich nur 2,5 Stunden pro Tag sind.
Nachteile eines Sprint Burn-Down-Charts mit Zeitaufwänden
Neben diesen Vorteilen bringen Sprint Burn-Down-Charts, die Aufwände in Form von Zeit visualisieren, auch einige Nachteile mit sich. Den erhöhten Aufwand im Sprint Planning habe ich bereits erwähnt. Es kann wirklich anstrengend sein, jede Aufgabe mit Stundenschätzungen zu versehen.
Kollaboratives Arbeiten wird untergraben
Wie schon erwähnt müssen Zeitaufwände von Aufgaben, an denen mehrere Entwickler arbeiten werden, (häufig) entsprechend multipliziert werden. Ein Refinement, das 2 Stunden dauert, an dem jedoch 5 Entwickler teilnehmen, schlägt direkt mit 10 Stunden zu Buche. Schnell wird dann die „Effizienzkeule“ geschwungen und kollaboratives Arbeiten systematisch untergraben: „Müssen da wirklich immer alle Entwickler mit dabei sein?!“
Story Points werden mit Stunden verglichen
Wenn Du so möchtest, erzeugt die Schätzung von Tasks in Zeit eine Art „Umwandlung“ von Story Points zu Stunden. Denn im Sprint Planning beginnt Dein Team ja beispielsweise damit, eine User Story mit 3 Story Points mit Tasks zu versehen und gleichzeitig Stunden für diese Tasks zu festzuhalten.
Einerseits kann das hilfreich sein, um Fehleinschätzungen aus dem Backlog Refinement sichtbar zu machen.
Stell Dir vor, in Eurem Sprint Backlog sind zwei User Stories mit 5 Story Points. Für die eine User Story schätzen die Entwickler 10 Stunden Zeitaufwand, für die Tasks der anderen User Story jedoch 25 Stunden. Die Frage wäre dann: Warum ist das so? Ist es, weil die zweite User Story vielleicht doch eher eine Größe von 8 Story Points hat? Oder liegt es daran, dass die erste User Story zwar zeitlich gesehen keinen großen Aufwand darstellt, aber Risiken existieren, die ihre Fertigstellung verzögern?
Andererseits liegt darin auch eine große Gefahr. Dein Team (und schlimmstenfalls die Stakeholder Deines Teams) beginnen damit, Story Points in Stunden umzurechnen (und umgekehrt). Story Points berücksichtigen jedoch auch Faktoren wie Komplexität, Risiken und Hindernisse. Deshalb lassen sich Stunden und Story Points nicht 1:1 vergleichen.
Aufwände sagen nichts über die Dauer aus
Eine weitere Gefahr besteht darin, den zeitlichen Aufwand für die Umsetzung einer User Story mit der Dauer, um sie zu erledigen, gleichzusetzen. Gerade in der Kommunikation mit Stakeholdern geht dann vieles schief.
Die Entwickler Deines Teams sagen dann beispielsweise, dass es 8 Stunden dauert, um etwas umzusetzen und viele Manager hören dann, dass die Aufgabe morgen fertig ist. Das gilt aber nur dann, wenn nur an dieser Aufgabe gearbeitet wird. Was jedoch fast nie der Fall sein wird.
Sprint Burn-Down-Chart mit Story Points
Die zweite Variante, die Ihr in Eurem Team nutzen könnt, ist ein Sprint Burn-Down-Chart mit Story Points. Die Methode ist dabei ausgesprochen simpel:
Jedes Mal, wenn während des Sprints eine User Story geschlossen wird, senkt Ihr den verbleibenden Aufwand auf dem Burn-Down-Chart um die entsprechenden Story Points dieser User Story.
Vorteile eines Sprint Burn-Down-Charts mit Story Points
Geringerer Pflegeaufwand
Das Aufschreiben, Tracken und Verändern aufgewendeter Stunden für jeden Task eines Sprints kann eine ziemlich umfangreiche Angelegenheit werden. (Selbst mit digitalen Tools wie Jira oder Azure DevOps.) Denn wer weiß schon immer so genau, wie lange er oder sie an einem konkreten Task gearbeitet hat? Haben zwei Entwickler gemeinsam an einer Aufgabe gearbeitet, muss die Stundenzahl entsprechend verdoppelt werden. (Obwohl das im Sprint Planning vielleicht noch nicht klar war.) Gleichzeitig muss die Anzahl der noch verbleibenden Stunden angepasst werden, falls klar wird, dass eine Aufgabe doch länger dauert, als ursprünglich gedacht.
Bei einem Burn-Down-Chart mit Story Points verringert Ihr einfach den aktuellen Stand an Story Points, sobald eine User Story umgesetzt wurde. Fertig!
Fokus auf Fortschritt statt Zeitaufwand
Ein weiterer großer Vorteil dieser Art Sprint Burn-Down-Chart ist der Fokus auf Fortschritt. Denn wenn Dein Scrum Team für sein Sprint Burn-Down-Chart Zeitaufwände und Kapazität nutzt, kann es durchaus sein, dass zwar die Stunden getrackt werden und das Burn-Down-Chart „gut aussieht“, aber zum Ende des Sprints nicht eine einzige User Story fertig ist.
Wenn Ihr hingegen fertige User Stories trackt, könnt Ihr durch das Sprint Burn-Down-Chart sehen, wie viele User Stories bereits geschlossen wurden. (So wird zum Beispiel auch sehr gut sichtbar, wenn Dein Team alle User Stories immer erst zum Ende des Sprints abschließt und erst kurz vor Torschluss fertig wird.)
Kleinere User Stories
Ein Burn-Down-Chart mit Story Points funktioniert natürlich nur dann wirklich gut, wenn das Sprint Backlog aus vielen möglichst kleinen User Stories besteht. (Also User Stories mit 1, 2 oder 3 Story Points.) Hat Dein Team lediglich eine User Story mit 20 SP im Sprint Backlog, sieht man im Burn-Down-Chart während des Sprints natürlich gar nichts.
Die Nutzung von Story Points für Euer Sprint Burn-Down-Chart hat daher auch einen „erzieherischen Nebeneffekt“. Denn sie zwingt Euch gewissermaßen dazu, User Stories, die (noch) zu groß sind, während Eures Refinements weiter zu verkleinern.
Das Release Burn-Down-Chart
Burn-Down-Charts lassen sich natürlich nicht nur für einen einzelnen Sprint nutzen, sondern auch bei der Entwicklung eines Produktes oder im Rahmen von Projekten. In diesem Fall spricht man von einem Release Burn-Down-Chart. (Manchmal wird es auch Product Burn-Down-Chart genannt.)
Das Release Burn-Down-Chart stellt eine große Hilfe für Dich als Produkt Owner dar, wenn es um die Kommunikation mit Stakeholdern und Kunden geht. Im Grunde funktioniert es genauso wie das Sprint Burn-Down-Chart (mit Story Points), das ich Dir bereits weiter oben vorgestellt habe.
Lediglich den Zeitraum, der über die X-Achse abgebildet wird, veränderst Du dabei von Tagen auf Sprints.
Mit dem Release Burn-Down-Chart Vorhersagen treffen
Beim Release Burn-Down-Chart hast Du zwei grundsätzliche Optionen, um Vorhersagen über potenzielle Release Dates zu treffen. Entweder Du nutzt die durchschnittliche Velocity Deines Teams oder Du verwendest die sogenannte Velocity Range. Letztere hat den Vorteil, dass Du einen zeitlichen Korridor visualisieren kannst, der umso größer wird, je weiter ein Release Date in der Zukunft liegt.
Release Dates mit Hilfe der Velocity ermitteln
Als Product Owner kannst Du die (historische) Velocity Deines Scrum Teams zur Ermittlung eines potenziellen Release Dates nutzen. Dabei kannst Du zunächst ganz simpel vorgehen:
Wenn Dein Team eine (durchschnittliche) Velocity von 10 SP hat und Dein Product Backlog umfasst Features mit insgesamt 200 SP, dann ist Dein Backlog (wahrscheinlich) nach 20 Sprints abgearbeitet.
Vorhersagen mit der Velocity Range treffen
Die durchschnittliche Velocity taugt jedoch nur zur groben Einschätzung. Was Du als Product Owner benötigst, ist ein Methode, die Dir dabei hilft, eine Art Zeit-Korridor zu ermitteln. Denn je weiter ein Datum in der Zukunft liegt, desto weniger genau sind ja auch Deine Prognosen.
Möglich wird das durch die sogenannte Velocity Range, die eine wunderbare Ergänzung für Dein Release Burn-Down-Chart ist.
Die Velocity Range besteht aus 3 (historischen) Kennzahlen Deines Scrum Teams.
Velocity Chart der letzten 7 Sprints
Nehmen wir einmal das rechts zu sehende Velocity Chart als Beispiel, dann liegt die minimale Velocity bei 5, die maximale Velocity bei 20 und der Median dieses Scrum Teams bei 8 SP.
Die Velocity Range auf dem Release Burn-Down-Chart
Wenn wir diese Velocity Range einmal auf unser Backlog-Beispiel mit 200 Story Points anwenden, kannst Du als Product Owner drei Trendlinien nutzen, um auf Deinem Release Burn-Down-Chart einen Zielkorridor zu visualisieren.
Wenn alles gut läuft, ist dieses Team bereits nach 10 Sprints mit allem fertig. Umgekehrt könnte es auch 40 Sprints dauern, falls die Velocity in jedem Sprint nur bei 5 liegt.
Der Median sagt Dir, dass 25 Sprints recht gut in der Mitte liegt. Die anvisierten 20 Sprints kann das Team aber wahrscheinlich nicht halten.
Trotzdem ist der Korridor zu Beginn Deines Projektes mit 10 bis 40 Sprints sehr groß.
Aktualisiere die Velocity Range nach jedem Sprint
Glücklicherweise kannst Du Dein Release Burn-Down-Chart von Sprint zu Sprint aktualisieren und daraus neue Erkenntnisse ableiten.
Nehmen wir einmal an, Du hättest das Projekt begonnen und bereits 5 Sprints durchgeführt.
Dadurch haben sich die Werte für die minimale und maximale Velocity, aber auch der Medianwert verändert.
Die minimale Velocity liegt nun bei 6 SP, die maximale Velocity ist weiterhin 20 SP. Der Medianwert liegt nun bei 12 SP pro Sprint.
Velocity Chart nach 5 weiteren Sprints
Außerdem kommt hinzu, dass sich der Scope Deines Projektes verringert hat. Denn Euer Team hat ja bereits 5 Sprints gearbeitet und den verbleibenden Aufwand auf 151 Story Points verringert.
Der Zielkorridor Deines Projektes liegt nun zwischen 13 und 34 Sprints, wobei der Median 18 Sprints prognostiziert. Damit sieht es nun schon deutlich positiver aus, die Deadline von 20 Sprint zu halten.
Auf dem Release Burn-Down-Chart sieht das Ganze folgendermaßen aus:
Scope-Veränderungen auf dem Release Burn-Down-Chart abbilden
Der Umfang eines Projektes bleibt natürlich in den seltensten Fällen konstant. Sehr häufig kommen im späteren Verlauf Aufwände hinzu, die zu Beginn nicht klar waren. Diese Scope-Veränderungen kannst Du in Deinem Release Burn-Down-Chart visualisieren, indem Du die Null-Linie weiter nach unten verschiebst.
Bleiben wir bei unserem Beispiel und nehmen an, dass im 5. Sprint wichtige Aufgaben hinzukommen, die einen geschätzten Aufwand von 20 Story Points haben. Dann sieht diese Veränderung auf dem Burn-Down-Chart so aus wie hier rechts zu sehen.
Die neuen Prognosen der Velocity Range kannst Du dann recht einfach ablesen. Dazu nutzt Du nicht mehr die ehemalige Null-Linie, sondern die darunter befindliche Scope-Linie.
Der Zeitkorridor für das fertige Projekt liegt damit bei 14 bis 37 Sprints. Der Medianwert prognostiziert 20 Sprints.
Alternativen zu Burn-Down-Charts
Neben Release und Sprint Burn-Down-Charts gibt es noch einige Alternativen.
Die bekannteste davon ist sicherlich das sogenannte Cumulative Flow Diagram (CFD), das bei der Anwendung von Kanban genutzt wird. Im Grunde ist ein CFD nichts anderes als ein Burn-Up-Chart, das jedoch nicht die Aufwände visualisiert, sondern lediglich die Anzahl von Work Items visualisiert.
Fazit zu Burn-Down-Charts
Wie Du siehst, sind Release und Sprint Burn-Down-Charts wirklich mächtige visuelle Tools! Auch wenn der Scrum Guide sie nicht direkt vorschreibt, kann ich Dir ihre Nutzung nur ans Herz legen.
Ob Ihr allerdings Eure Aufwände im Sprint Burn-Down-Chart mit Stunden oder mit Story Points visualisiert, ist sicherlich Geschmacksache beziehungsweise persönliche Vorliebe. Das Gleiche gilt natürlich auch für die Nutzung von durchschnittlicher Velocity, Medianwert oder Velocity Range beim Release Burn-Down-Chart.
Experimentiert mit verschiedenen Varianten und probiert sie einfach verschiedene Vorgehensweisen aus. Denn nur so könnt Ihr herausfinden, was am besten für Euer Team passt.
