Burndown Chart in Scrum

In Scrum übernehmen die Entwickler eine hohe Verantwortung im Scrum Team. Sie sind für die eigenverantwortliche Ausgestaltung der Arbeit im Sprint zuständig. Dafür müssen die Entwickler im Sprint proaktiv auf neue Erkenntnisse reagieren. Leider sind viele Entwickler es nicht gewohnt, diese Verantwortung zu tragen. Sie erkennen oft erst zu spät, dass der Sprint aus dem Ruder läuft.

Tun sich aber die Entwickler hier schwer, reaktiviert dies leicht „alte Micromanager“. Dies verunselbstständigt die Entwickler, statt sie zu mehr Eigenverantwortung zu entwickeln. So kann aber niemals ein effektives Scrum Team entstehen, was einem wirklich weiterhilft.

Richtig genutzt können Burndown Charts in Scrum ein wichtiges Hilfsmittel sein. Es hilft dabei früh zu erkennen, wenn der Sprint aus dem Ruder läuft. Ein Anstoß, der vielen Entwicklern hilft proaktiv im Sprint nachzusteuern.

In Podcast #11 „Überwachung des Sprint-Fortschritts“ wird diese Problematik genau besprochen. Hier wird die Funktion von Burndown Charts erklärt, wofür sie gedacht sind und wie sie dem Team im Sprint helfen können, Ownership zu übernehmen.

Was ein Burndown Chart nicht ist

In vielen Organisationen konzentrieren sich die Entwickler auf ihre isolierte Aufgabe. Sie sind es gewohnt, dass ein Manager den Überblick behält und bei Bedarf nachsteuert.

Aus alter Gewohnheit zweckentfremden viele Scrum Teams den Burndown um zu meinem Management-Tool:

• Der Burndown Chart wird fürs Statusreporting genutzt
• Als Datengrundlage für die Überwachung der Arbeit im Sprint durch das Management 
• Für den PO, der sich ebenfalls verantwortlich fühlt für das, was im Sprint passiert

Genau für diese Zwecke ist ein Burndown Chart nicht gedacht. Es geht bei der Überwachung des Sprint-Fortschritts nicht darum, das Team zu kontrollieren, sondern vielmehr darum, ein Hilfsmittel zu bieten, welches das Team unterstützt, seine Arbeit unter Kontrolle zu haben und Verantwortung zu übernehmen.

Scrum schreibt (laut Scrum Guide) nicht vor, wie wir den Sprint-Fortschritt überwachen. Die Erwartung ist nur, dass ein Entwicklungsteam Ownership übernimmt und weiß, wo es mit seiner Arbeit steht und wo es nachsteuern muss. Dafür kann auch die Erweiterung des Sprint Backlogs zu einem Task Board ausreichen. In der Praxis werden Burndown Charts sehr häufig genutzt, um den Sprint Fortschritt zu überwachen, da sie die relevanten Informationen verdichten und prägnant veranschaulichen.

Wofür Burndown Charts wirklich gedacht sind

Burndown Charts sind dafür gedacht, dem Team einen Überblick und die Kontrolle über die  Arbeit im Sprint zu geben. Um dies zu erreichen, braucht es ein Entwicklungsteam, das die Verantwortung für den Sprint übernimmt und frühzeitig in der Lage ist, im Sprint nachzusteuern. Es muss proaktiv handeln und zeigen, dass  es seine Arbeit unter Kontrolle hat, vertrauenswürdig ist und bei Bedarf die Umwelt über Veränderungen informiert. Bei Bedarf bedeutet allerdings nicht, einfach nur auf Grundlager der aufgezeigten Linie im Burndown Chart zu agieren, sondern vielmehr auf Grundlage der Rückschlüsse, die das Team (und nur das Team) aus dem Burndown Chart zieht. Genau um dieses proaktive Handeln zu unterstützen, bildet das Burndown Chart zwei unterschiedliche Dimensionen anhand zweier Achsen ab: Die Zeit im Sprint und die offene Arbeit im Sprint.

In diesem Chart wird der aktuelle Fortschritt im Sprint festgehalten. Um Probleme deutlicher erkennbar zu machn, beinhalten Burndown Charts immer auch eine Ideallinie. Die Ideallinie bewirkt, dass Teams sich kritisch mit dem Fortschritt im Sprint auseinandersetzen – vor allem dann, wenn der Fertigstellungsgrad über der Ideallinie liegt und das Team erkennt, dass es mit der Arbeit (verglichen mit der Ideallinie) zurückliegt. Genauso ist ein Wert unter der Ideallinie ein Indikator dafür, potentiell noch Luft im Sprint zu haben.

Wichtig ist dabei, dass eine kritische Auseinandersetzung mit den Informationen erfolgt, die ein Burndown Chart liefert. Das Chart sollte als eine Art Einladung für ein Gespräch genutzt werden, denn die Daten sprechen nicht zwangsweise für sich selbst. Das Team verfügt über das notwendige Wissen zum Kontext und kann so die Daten dementsprechend deuten. Eine isolierte Betrachtung ist nicht ratsam, denn selbst wenn das Burndown Chart “schlecht” aussieht, kann ein Team dennoch alles im Griff haben. Umgekehrt kann ein Team, selbst wenn das Burndown Chart “gut” aussieht, den Sprint aus irgendeinem Grund nicht schaffen. Es geht darum, die aktuelle Lage zu kennen und darüber zu sprechen. 

Burndown Chart: Tasks vs Stories? 

Im Burn-Down Chart kann man unterschiedliche Einheiten nutzen, um die offene Arbeit darzustellen. 

Gern werden Burndown Charts auf Basis von Tasks geführt. Meiner Meinung nach weist diese Art der Darstellung gewisse Schwachpunkte auf. Ich werde sie im Folgenden dennoch aufzeigen und im Kontrast dazu meine präferierte Einheit, die Darstellung der Arbeit anhand von Backlog Items, erläutern.  

1. Burndown Chart auf Basis von Tasks

Im Sprint Planning können Backlog Items in Tasks heruntergebrochen werden (mehr Informationen zum Task Board und den Tasks findest hier), Diese Tasks können entweder auf Basis ihrer Anzahl oder anhand der Summe der geschätzten Stunden als Startzustand im Burndown Chart eingetragen werden.

Das Team aktualisiert das Chart während des Sprints kontinuierlich und visualisiert auf der Zeitlinie die noch vorliegende Anzahl an offenen Task. Dies kann entweder täglich manuell (beispielsweise im Daily) oder über automatische Updates mithilfe eines Tools erfolgen. Die daraus entstandene Übersicht kann beispielsweise im Sprint Planning als Indikator genutzt werden um zu erkennen, ob ein Team nachsteuern muss.

Die bereits erwähnte Dysfunktion resultiert aus der Granularität und dem hohen Detailgrad der einzelnen Tasks.

Nutzen wir Tasks zur Darstellung unseres Sprint-Fortschritts, kann es passieren, dass das Burndown Chart positiver dargestellt wird, als die Situation tatsächlich ist. Dadurch, dass wir eine detaillierte Darstellung unseres Backlogs betrachten, kann es vorkommen, dass einfache Tätigkeiten zuerst gewählt werden und schwierige Tasks lange liegen bleiben. Das Resultat ist, dass das Team  viel zu spät im Sprint darauf eingeht, worauf es ankommt und dadurch sehr schlecht nachsteuern kann. Darüber hinaus wird diese Darstellung zum Problem, wenn wir einzelne Tasks vergessen. Dies ist aufgrund des hohen Detailgrades der Darstellung und der anspruchsvollen Arbeiten, die wir mit Scrum angehen, völlig normal. Die Notwendigkeit, Items zu ergänzen wird allerdings erst im Verlauf des Sprints klarer und führt daher gegen Ende des Sprints zu einem Anstieg an Tasks. 

Die Fokussierung auf einfache Tasks am Anfang des Sprints in Kombination mit dem nachträglichen Hinzufügen von vergessenen Tasks führt dazu, dass kurz vor Ende des Sprints die Anzahl an Tasks steigt und die Komplexität der Items zusätzlich sehr hoch ist.  Das Team erkennt zu spät, dass es sich übernommen hat. Das Resultat ist ein überfüllter Sprint. Aus diesen Gründen empfehle ich lieber einen Burndown Chart auf Basis von Backlog Items zu erstellen.

2. Burndown Chart auf Basis von Backlog Items

Bei der Darstellung der Arbeit durch Backlog Items wird verbleibende Arbeit anhand von Backlog Backlog Items im Burndown Chart ein eingetragen. Es handelt sich hierbei in den meisten Fällen um User Stories. Diese können einfach nach ihrer Anzahl aufsummiert oder in relativer Schätzung zueinander dargestellt werden. Jedes mal, wenn ein Backlog Item zu 100% abgeschlossen ist, fällt die Linie im Chart entsprechend.

Warum diese Variante meine präferierte Darstellung ist, lässt sich einfach verdeutlichen: Diese Variante des Burndown Chart ist pessimistischer, da die “Linie” sich erst mit einem abgeschlossen zu 100 % abgeschlossenen Item verringert. Dadurch schafft sie den richtigen Fokus für das Team. Ein Vorarbeiten mit einfachen Tätigkeiten gibt uns keinen Scheinvorteil mehr.

Das Burndown Chart wird hier zu einem Indikator, der sehr früh Probleme aufzeigt, auf die wir dementsprechend eingehen können. Darüber hinaus fördert diese Darstellung eine neue Arbeitsweise: Um nah an der Ideallinie arbeiten können, benötigen Teams einen Austausch. Integriert man dieses Chart beispielsweise in einer guten Art und Weise als Trigger für ein Gespräch in das Daily, kann es genau der Anstoß sein, früh gegenzusteuern um erfolgreich mit Scrum zu arbeiten.

In Scrum arbeiten wir anders!

Steigt man auf Scrum um,  muss man sich immer wieder bewusst werden über die Andersartigkeit dieser Arbeitsweise. Waren wir es vorher gewohnt,  alleine vor uns hinzuarbeiten, so ist es das Ziel mit Scrum, in extrem enger Zusammenarbeit mit unterschiedlichen Expertisen ein Ergebnis zu produzieren, und weg von der scheinbar effizienten Arbeitsweise unterschiedlicher Disziplinen zu kommen. 

Am Anfang ist auch die Nutzung eines Burndown Charts ungewohnt. In den allermeisten Fällen verläuft die Linie flach, weil wir uns schwer tun, im Sprint etwas abzuschließen. Der Grund dafür ist, dass jeder versucht, an “seinem” Item alleine und entsprechend seiner Profession nachzugehen. Was sich oft gut anfühlt, ist in der effektiven Arbeit mit Scrum nicht hilfreich. Wir weichen uns aus.  Wenn jeder seinem eigenen Thema nachgeht, lebt das Team sich auseinander. Dies widerstrebt jedoch der Grundintention von Scrum, denn die Idee war es, eine enge Zusammenarbeit als Team zu ermöglichen um schnell zu liefern und über Grenzen hinweg gemeinsam die Synergien zwischen den Disziplinen zu nutzen.

Erfolgreiche Entwicklungsteams arbeiten also im Vergleich zu früher (vor Scrum) anders und sind dadurch effektiver. Und das ist auch gut so, denn: Wenn nichts anders wäre, könnten man auch kaum andere Ergebnisse erwarten. Man kann sogar behaupten, dass Scrum bei einer Ansammlung von Individuen, die ihre Arbeit isoliert bestreiten, kaum noch Sinn macht. Im Gegenteil:  Es entsteht Unmut darüber, “ständig” Meetings abhalten zu müssen, die beim Abarbeiten stören. Ein unausweichliches Resultat, wenn man eine teamorientierte Methode ohne echte Teamarbeit einsetzt.

Enge Zusammenarbeit im Team fördern

Es gibt verschiedene Wege, wie wir eine enge Zusammenarbeit im Team fördern können. Ich möchte hier einige Ideen vorstellen, wie ich das angehe.   

• • Das Daily kann um die Frage “Was fehlt?” ergänzt werden, um das nächste Item abzuschließen

• • Es kann in der Planung darauf eingegangen werden, wie wir das erstes Item früh abschließen können

• • Es kann hilfreich sein, das erste Item gemeinsam anzugehen und eine Belohnung für die Fertigstellung für den kommenden Tag ausloben

• • Es macht Sinn, das Thema Zusammenarbeit in der Retro anhand folgender Fragestellungen ans Team aufzugreifen
    • • Wie können wir in engerer Zusammenarbeit schneller Items abschließen?
    • • Welche Skills müssen besser verteilt werden?
    • • Was an unserer Arbeitsweise hält uns zurück?

• • Die Teamarbeit wird gefördert, wenn Burndown Charts auf Basis von Backlog Items benutzt werden 

Eine enge Zusammenarbeit im Team verbessert letztendlich nicht nur das Burndown Chart, sondern es schafft auch einen anderen Spirit und eine Dynamik, Ergebnisse zu erzielen. Das Team arbeitet dadurch effizienter, managed Risiken besser und es hat mehr Spaß bei der Arbeit.   „

Zusammenfassung

Das Sprint Monitoring wird oft für die Befriedigung des Informationsbedürfnisse der alten Arbeitsweise benutzt und erzeugt dadurch Dysfunktionen. Es ist eigentlich ein Trigger, um im Team zu arbeiten und sich auszutauschen – auch wenn es ungewohnt ist. Alternativ zum Burndown Chart kann auch ein  Task Board dafür genutzt werden. Ein Burndown Chart bleibt stellt allerdings ein deutlich konkreterer Anstoß für ein Gespräch dar. Burndown Charts basierend auf Tasks sind oft zu optimistisch und erzeugen Dysfunktionen. Burndown Charts auf Basis von Backlog Items sind weniger optimistisch. Sie forcieren den Austausch und zudem, dass das Team seine Arbeit umstellt und eng zusammenarbeitet. 

Ergänzende Perspektiven

Podcast Nachlese

Aufbauend auf dieser Folge habe mit Andreas Schliep ausgetauscht gesprochen.

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube immer entsperren