Diese Seite setzt Cookies ein, um das Nutzerlebnis zu verbessern. Durch Klick auf "OK" erklärst Du Dich damit einverstanden. Mehr dazu gibt es unter Datenschutz.

OK

Burndown Basics

Der Burndown Graph ist sozusagen der Standardreport wenn man bspw. mit Scrum unterwegs ist. Ein genauere Beschäftigung mit dem Thema lohnt sich: was kann es und was kann es nicht?

Ein Burndown-Chart das die verbleibenden Restaufwände anzeigt.

Ein Burndown-Chart das die verbleibenden Restaufwände anzeigt.

Die blaue Kurve zeigt die verbleibenden Restaufwände (die sind auf der Y-Achse abgebildet) und die X-Achse zeigt den Zeitraum. In rot die Ideallinie – wie sich die Restaufwände bei perfekt linearem Fortschritt über den Zeitraum entwickeln würden.

Schaut erstmal unspektakulär aus. Und das ist eine der Stärken dieser Auswertung – so richtig viel kann man da nicht falsch machen. Es handelt sich ganz einfach um eine Kurve oder eine Linie die die Entwicklung der Restaufwände – sei es in geschätztem Aufwand oder in Story Points – über einen Zeitraum nachzeichnet. Der Einfachheit halber gehe ich – wo nicht explizit erwähnt – immer davon aus dass alle Stories geschätzt sind und der Scope stabil.

Was sagt so ein  Burndown Graph aus?

Ein Burndwon-Chart das gebuchte und verbleibende Aufwände zeigt.

Ein Burndown-Chart das gebuchte und verbleibende Aufwände zeigt.

Das Burndown sagt mir zuerst mal nur wieviel von den Aufwänden die ich mir vorgenommen habe noch übrig ist (die blaue Kurve). Wenn ich mir für einen zweiwöchigen Sprint zehn Tage Aufwand vornehme und fünf Tage vor Sprintende noch acht Tage Aufwand offen sind, deutet dies auf ein Problem hin. Ich werde das was ich mir vorgenommen habe vermutlich nicht schaffen.

Möglicherweise habe ich mich verschätzt und die Stories sind aufwändiger / komplexer als ich mir das gedacht hatte. Vielleicht kann ich sie aber auch aufgrund von externen Abhängigkeiten nicht bearbeiten. Oder – komplett anderer Grund – ich arbeite an was ganz was anderem. Logisch dass ich dann bei den Stories die ich ursprünglich bearbeiten wollte keine Fortschritte erziele.

In jedem Fall sollte ich mal nachschauen ob ein Problem vorliegt und wenn möglich gegensteuern.

Aber die Sache ist auch anders herum denkbar: Wieder fünf Tage vor Sprintende, diesmal sind aber nur noch zwei Tage Aufwand offen. Ich bin also schneller als gedacht. Und auch hier können die Ursachen vielfältig sein.

Habe ich mich verschätzt? Sind die Tasks einfacher / weniger komplex als angenommen? Sind Stories (und mit ihnen ihre Aufwände) gestrichen worden? Stichwort „Feature Cut“. Das sind nur zwei mögliche Gründe.

Und auch da sollte ich mich hinsetzen und mal Gedanken machen. Wieso wurden die Stories gestrichen? Wenn vorher absehbar war dass sie nicht gebraucht werden – wieso sind sie nicht früher gestrichen worden? Wenn ich mich verschätzt habe (egal ob nach oben oder nach unten), sollte ich prüfen ob das regelmäßig passiert. Eventuell habe ich ein Problem was meine Schätzgenauigkeit angeht (denkbare Ursache: die Stories sind nicht ausreichend belastbar).

Schon aus diesen beiden Möglichkeiten – ich bin schneller bzw. langsamer als geplant – lassen sich eine Menge Ansatzpunkte ableiten, die es zu prüfen gilt. Das Burndown ist eine Art Seismograph, es sagt mir dass da etwas ist, aber nicht unbedingt was. Das muss ich dann selbst herausfinden.

Logged work

Was man auch immer wieder sieht: Eine zweite Kurve (hier schwarz) die zeigt wieviel Aufwand gebucht wurde. Das ist eine ziemlich hilfreiche Information.

Im Idealfall spiegelt die eine Kurve die andere. Die Annahme ist dass die blaue Kurve (die Restaufwände) in dem Maße sinkt wie ich Aufwand (also Zeit, die schwarze Kurve) hineinstecke. Geht die blaue runter, geht die schwarze hoch. Wie gesagt: der Idealfall. Schauen wir mal in die Realität. Auch hier gilt: blau = Restaufwände, schwarz = geleistete Arbeit.

  1. Die blaue Linie fällt stärker als die schwarze ansteigt – hier habe ich mit weniger Einsatz das Ziel erfüllt, ich bin schneller als geschätzt. Extremfall: schwarz bleibt flach, blau rauscht runter. Ohne Einsatz sind die Restaufwände geringer geworden. Stories gestrichen?
  2. Die schwarze steigt stärker als die blaue fällt – ich stecke mehr Aufwand hinein als gedacht, bzw. erziele damit nicht den Effekt den ich mir erwartet habe. Extremfall: blau bleibt flach, schwarz schnellt in die Höhe. Ich arbeite, komme aber nicht voran.
  3. Beide Kurven, blau und schwarz, bleiben flach. Dann muss ich mich fragen: was mache ich die ganze Zeit? Entweder ich arbeite garnicht. Oder ich arbeite an etwas, das nicht auf mein Ziel einzahlt (hier: die Stories die die Basis für das Burndown sind).

Wow. Eine ganze Menge für so ein einfaches Chart. Ich denke nun wird klar warum der Burndown Graph so eine zentrale Stellung hat. Das Ding ist einfach zu erstellen, man kann nicht so viel dabei falsch machen und bildet so ziemlich alles ab was so passieren kann.

Was sagt so ein Burndown Graph nicht aus?

Bleibt die blaue Kurve flach, gibt es noch eine weitere Erklärungen. Diese sollte ich als erste prüfen. Mein Burndown (hier vereinfacht, nur die blaue Kurve) sieht dann etwa so aus:

Ein Burndown-Chart das späte Aufwandsbuchungen zeigt.

Ein Burndown-Chart das späte Aufwandsbuchungen zeigt.

Was steckt nun dahinter? Zur Erinnerung: Bisher habe ich zwei mögliche Ursachen auf dem Schirm. Die erste ist, dass ich die Restaufwände nicht runter bekomme obwohl ich Zeit reinstecke, bzw. blockiert bin. Die zweite ist dass ich an etwas anderem arbeite das nichts mit dem Scope des Sprints (oder des Projekts) zu tun hat.

Es gibt aber auch eine dritte mögliche Ursache: *Trommelwirbel* Das Team hat keine Aufwände gebucht bzw. aktualisiert die Restaufwände nicht. Total banal, aber ein Riesenproblem. Beide Kurven sind dann flach. Also hin und wieder das Team daran erinnern – dabei wirkt ein aktuelles Burndown am Taskboard übrigens Wunder!

Da vier bekanntlich gewinnt, die vierte Ursache: Die Schätzungen sind unvollständig. Noch so ein Kardinalfehler. Ich kann noch so viel Zeit investieren, die Restaufwandskurve geht nicht runter (schwarze Kurve steigt, blaue bleibt flach). Also immer alle Aufwände – zur Not grob – schätzen. Im Burndown müssen alles Umsetzungsaufwände des Teams berücksichtigt sein. Sollte eigentlich klar sein, wird leider trotzdem zu oft nicht beachtet.

Ähnlich wie beim Velocity Chart sagt das Schaubild nichts darüber aus wie sinnvoll die Stories als solche sind. Das muss im Planning geklärt werden bzw. noch einen Schritt früher, wenn der Product Owner das Backlog priorisiert.

Wo begegnet einem ein Burndown Graph in freier Wildbahn?

Falls das Burndown sich mal nicht blicken lassen sollte – der örtliche Scrum Master weiß wo es anzutreffen ist und hilft gerne bei der Suche. Oft kommt das Burndown im Doppelpack vor: das Sprint-Burndown und sein großer Bruder das Projekt-Burndown.

Der Unterschied? Eingangs hatte ich ja gesagt dass das Burndown die Entwicklung der Aufwände über einen bestimmten Zeitraum abbildet. Nun, der Name der beiden Variante verrät es schon: Während das Sprint-Burndown die Stories in einem Sprint und deren geschätzten Aufwand als Basis hat, bildet das Projekt-Burndown alle zum Scope eines Projekts gehörenden Stories mit ihren Aufwänden ab. Und es ist immer gut beide Varianten parat zu haben.

Fazit

Ein Burndown Graph ist Standard. Das hat man einfach und bei Scrum verzichtet man nicht darauf. Auch nicht ausnahmsweise. Es gibt einige, wenige Dinge die man beachten muss:

  1. Immer ein Burndown haben.
  2. Die Datenbasis muss korrekt sein – Grundlage sind die Stories im Sprint bzw. die Stories des Projektscopes.
  3. Die Stories müssen alle geschätzt sein – entweder die Stories im Sprint, oder wenn ich ein Projekt mit fixem Scope habe der gesamte Umfang des Projekts. Hier gilt: lieber eine grobe Schätzung als keine.
  4. Das Team muss die Aufwände aktuell halten – die geleisteten und die noch zu erwartenden.

Gar nicht so schwer, ne? Also machen!

Verwandte Artikel

Schönen Sonntag!