4.8 4 Votes
Artikel-Rating

In diesem Artikel stelle ich Dir das Sprint Burndown Chart vor. Es ist ein von Scrum Teams häufig verwendetes Tool, das die Entwickler in ihrer Selbstorganisation unterstützt, da es die noch zu erledigende Arbeit visualisiert. Deshalb ist es sehr hilfreich, wenn es darum geht zu ermitteln, ob das Sprintziel in Gefahr ist.

Beim Sprint Burndown Chart habt Ihr grundsätzlich zwei Möglichkeiten, die noch verbleibende Arbeit zu visualisieren. Entweder Ihr nutzt dazu eine Aufwandsschätzung in Stunden oder in Story Points. Beides hat Vor- und Nachteile, auf die ich hier ausführlich eingehen werde.
0
Welche der beiden Varianten nutzt Ihr aktuell in Eurem Scrum Team? Und wie sind Eure Erfahrungen damit?x

Gründe für ein Sprint Burndown Chart

Der Hauptgrund für die Nutzung eines Sprint Burndown Chart ist das Selbstmanagement der Entwickler Deines 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, dieses zu erreichen. Und dieser Plan ist nichts anderes als das Sprint Backlog:

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

Die Punkte real-time picture of the work und inspect their progress sind hier besonders wichtig ist.

Mehr Transparenz durch ein Sprint Burndown Chart

Das Sprint Backlog dient also dazu, Transparenz darüber zu erzeugen, wie es um die Erreichung des Sprintziels steht. Gleichzeitig sind die Entwickler des Scrum Teams dafür verantwortlich sind, am Ende des Sprints auch ein nutzbares Increment zu liefern. Deshalb müssen sie natürlich möglichst gut einschätzen können, wie es aktuell um ihren ursprünglichen Plan bestellt ist.

Eine einfache Liste und sogar ein Kanban Board sind dabei oft nur bedingt hilfreich. Deshalb hat sich bei den meisten Scrum Teams die Nutzung eines Sprint Burndown Charts etabliert. (Auch wenn es kein fester Bestandteil des Scrum Guides ist!) Aber da das Sprint Burndown Chart ein visuelles Tool ist, unterstützt es die Entwickler dabei, einschätzen zu können, ob das Sprintziel (noch) erreicht werden kann.

Wenn Du so möchtest, ist das Sprint Burndown Chart eine zusätzliche (und sehr hilfreiche) Visualisierung des Sprint Backlogs.

Inspect & Adapt

Wenn die Entwickler mit Hilfe des Sprint Burndown Charts erkennen, dass das Sprintziel in Gefahr ist, haben sie prinzipiell drei unterschiedliche Optionen.

  • Sie beschließen selbstorganisiert, ihren Plan entsprechend anzupassen, sodass sie das Sprintziel weiterhin erreichen können. (Diese Option wäre auch gleichzeitig der Optimal-Fall.)

  • Sie erkennen, dass sie sich im Sprint Planning verschätzt haben und die Umsetzung aufwändiger ist als ursprünglich gedacht. Die Entwickler können dann in den Dialog mit ihrem Product Owner suchen und gemeinsam entscheiden, ob und wie der Scope des Sprints verringert werden kann. (Bestenfalls ohne das Sprintziel zu gefährden.)

  • Die Entwickler erkennen die Auswirkungen bestimmter Impediments, die sie (noch) nicht eigenständig lösen können. Sie können dannin den Dialog mit ihrem Scrum Master gehen. Dieser kann dann die Aufgabe übernehmen, das Hindernis aus dem Weg zu räumen, oder Hilfestellung bei der eigenständigen Beseitigung des Hindernis geben.

Aufbau eines Sprint Burndown Charts

  • Die X-Achse des Sprint Burndown Charts zeigt den zeitlichen Verlauf. (Üblicherweise unter Ausschluss von Wochenenden und Feiertagen.)

  • Über die Y-Achse wird der verbleibende Aufwand abgebildet.

Beim Sprint Burndown Chart existieren hierbei grundsätzlich zwei Varianten. Entweder Ihr schätzt bereits im Sprint Planning den zeitlichen Aufwand (in Stunden) oder Ihr verwendet dazu Story Points.

Gundgerüst eines Burndown Charts

Idealtrend & verbleibender Aufwand

Unabhängig davon, ob Ihr Story Points oder Stunden für die Aufwandsschätzung nutzt, trag Ihr in Euer Sprint Burndown Chart zwei verschiedene Graphen ein. Erstens den sogenannten Idealtrend und zweitens den aktuell verbleibenden Aufwand.

  • Der Idealtrend ist eine gerade Linie, die vom anfänglichen Aufwand zu Beginn des Sprints bis zur Null-Linie am letzten Tag des Sprints verläuft.

  • Der aktuell verbleibende Aufwand wird während des Sprints mindestens täglich aktualisiert.

Idealtrend & verbleibender Aufwand

Die fortlaufende Visualisierung des aktuellen Aufwands im Vergleich mit der Ideallinie hilft den Entwicklern Deines Scrum Teams dabei, möglichst gut einzuschätzen, ob zum Ende des Sprints auch wirklich alles fertig ist.

Sprint Burndown Chart mit zusätzlicher Trendlinie

Falls Ihr Euch noch mehr Transparenz wünscht, könnt Ihr Euer Sprint Burndown Chart noch um eine Trendlinie ergänzen.

  • Die Trendlinie ist eine gerade Linie, deren Startpunkt beim ursprünglichen Aufwand beginnt und dann durch den letzten aktuellen Stand verläuft.

Die Trendlinie visualisiert den tatsächlichen durchschnittlichen Aufwand, der bisher durch das Team erbracht wurde. Dadurch könnt Ihr im Verlaufe des Sprints besser erkennen, wo Ihr (wahrscheinlich) am Ende rauskommt.

Auf der rechten Seite siehst Du ein Sprint Burndown Chart mit einer Trendlinie, die auf dem Stand des fünften Tages eines Sprints basiert. Wenn dieses Scrum Team nichts unternimmt, kann es davon ausgehen, sein Sprintziel nicht zu erreichen.

Sprint Burndown Chart mit Trendlinie

Sprint Burndown Chart mit Zeitaufwänden

Viele Scrum Teams schätzen die notwendigen Stunden für die zu erledigenden Aufgaben (Tasks) des Sprints und visualisieren diesen dann als zeitlichen Aufwand auf ihrem Sprint Burndown Chart. Dieses Vorgehen hat einige Vor- als auch Nachteile, auf die ich im Folgenden genauer eingehe.

Zunächst einmal muss sich das Team gemeinsam darüber Gedanken machen, wie viele Stunden pro Sprinttag es für die tatsächliche Arbeit am Produkt aufwenden kann. Wenn es beispielsweise zu dem Schluss kommt, insgesamt 5h pro Tag aufzuwenden und das Team insgesamt 6 Entwickler hat, kommen wir auf eine Kapazität von insgesamt 270h bei einem 14-tägigem Sprint. (5h × 9 Arbeitstage × 6 Entwickler)

Sprint Burndown Chart mit Zeitwand

Im Sprint Planning muss dieses Team für jede Aufgabe, die notwendig ist, um eine User Story umzusetzen, eine Stundenschätzung festhalten. Im Planning selbst ist das durchaus hilfreich, weil das Team bereits im Sprint Planning erkennt, dass es sich vielleicht zu viel vornimmt. (Oder noch „Luft nach oben“ hat.)

Gleichzeitig erzeugt diese Form des Plannings ziemlich viel Aufwand. So muss beispielsweise bereits im Planning notiert werden, wenn 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 festgehalten werden.

Verbleibende Kapazität ist sichbar

Wenn Ihr in Eurem Scrum Team die Kapazitäten beim Sprint Planning ermittelt und beispielsweise auch Urlaubstage etc. festhaltet, dann ergibt sich dadurch eine weitere Linie, die auf dem Sprint Burndown Chart angezeigt werden kann.

Hier rechts siehst Du beispielsweise ein Team, bei dem am sechsten Sprinttag vier von fünf Entwicklern nicht am Sprint arbeiten können. Dadurch ergibt sich auf dem Burndown Chart ein sichtbarer Knick in der blauen Linie, welche 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 hilfreich sein.

Sprint Burndown mit Ideallinie & Kapazität

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 schätzen.

Einerseits kann das hilfreich sein, um Fehleinschätzungen im 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 10h Zeitaufwand, für die Tasks der anderen User Story jedoch 25h. 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.

Auswertung eines On Product Index

Die Nutzung von Stunden beziehungsweise Zeit für ein Sprint Burndown 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, 6h pro Tag am Sprint arbeiten zu können. Durch eine Auswertung vergangener Sprints können sie aber klar erkennen, dass es tatsächlich nur 2,5h pro Tag sind.

Im Evidence-Based Management gibt es dazu eine Kennzahl, die sich On Product Index nennt. Sie stellt das Verhältnis von tatsächlicher Arbeitszeit am Produkt zu insgesamt verfügbarer Zeit dar.

Legst Du 7,5h pro Arbeitstag zugrunde, die Entwickler arbeiten aber nur 2,5h pro Tag wirklich am Produkt, beträgt der On Product Index 33 %.

  • Mehr übder den On Product Index erfährst Du alsbald in einem meiner nächsten Artikel!

Insgesamt ist der On Product Index sehr hilfreich, um in einer gemeinsamen Sprint Retrospektive mögliche Impediments zu identifizieren und gemeinsam Lösungen zu entwickeln, die verfügbare Zeit für die Aufgaben des Sprints zu erhöhen.

  • Eine mögliche Maßnahme wäre beispielsweise eine (tägliche) gemeinsame Fokuszeit zu bestimmten Uhrzeiten. Bestenfalls sogar ein ganzer Tag, an dem keine Meetings stattfinden (dürfen).

Sprint Burndown Chart mit Story Points

Die zweite Variante ist ein Sprint Burndown Chart mit Hilfe von Story Points. Das heißt, jedes Mal, wenn während des Sprints eine User Story geschlossen wird, verändert sich das Burndown Chart entsprechend der dazugehörigen Story Points dieser User Story. Diese Variante hat meiner Erfahrung nach drei wichtige Vorteile.

  • Geringerer Pflegeaufwand

  • Fokus auf Fortschritt statt Zeitaufwand

  • Kleine(re) User Stories

Sprint Burndown Chart mit Story Points

Geringerer Pflegeaufwand

Das Aufschreiben, Tracken und Verändern von aufgewendeten 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 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 noch nicht klar war.) Gleichzeitig muss die Anzahl der noch übrigen Stunden angepasst werden, falls klar wird, dass eine Aufgabe doch länger dauert als ursprünglich gedacht.

Fokus auf Fortschritt statt Zeitaufwand

Ein weiterer großer Vorteil dieser Art des Sprint Burndown Charts ist der Fokus auf Fortschritt. Denn wenn Dein Scrum Team für sein Sprint Burndown Chart Zeitaufwände und Kapazität nutzt, kann es durchaus sein, dass zwar die Stunden getrackt werden und das Burndown 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 über das Sprint Burndown 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.

Positiver Nebeneffekt: Kleine User Stories

Ein Sprint Burndown 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 Sprint Burndown Chart während des Sprints natürlich gar nichts.

Die Nutzung von Story Points für Euer Sprint Burndown Chart hat daher auch einen „erzieherischen Nebeneffekt“. Denn sie zwingt Euch gewissermaßen dazu, User Stories, die (noch) zu groß sind, während des Refinements weiter zu verkleinern.

Fazit zum Sprint Burndown Chart

Wie Du siehst, ist das Sprint Burndown Chart ein wirklich mächtiges visuelles Tool! Auch wenn der Scrum Guide es nicht direkt vorschreibt, kann ich Dir die Nutzung nur ans Herz legen. Ob Ihr dabei Eure Aufwände in Stunden oder in Story Points trackt, ist wohl Geschmacksache. Oft ist das auch abhängig von der jeweiligen Situation.

Scrum Teams, die gerade erst beginnen, haben meiner Erfahrung nach eine Tendenz, sich für ihre ersten Sprints zu viel vorzunehmen. Sie überschätzen sowohl ihre verfügbare Zeit als auch die tatsächliche Dauer bestimmter Aufgaben. Hier kann es sehr lehrreich sein, Stundenaufwände zu schätzen und sie über das Burndown Chart abzubilden. Für Teams, die bereits länger mit Scrum arbeiten, empfehle ich Dir, Story Points für das Burndown Chart zu nutzen, da es den Fokus stärker darauf lenkt, Dinge fertig zu stellen.

Mich interessiert natürlich auch, wie Ihr ein Eurem Team Aufwände schätzt! Nutzt Ihr Stunden oder Story Points für Euer Sprint Burndown Chart? Welche Erfahrungen habt Ihr damit gemacht? Oder nutzt über überhaupt kein Sprint Burndown Chart? Schreib mir gerne einen Kommentar unter den Artikel! Ich freu mich auf Deine Meinung zu Sprint Burndown Charts!