Burndown Charts im Sprint?

Diese Woche habe ich mich mit einem Kunden über den Nutzen von Burndown Charts zum Messen des Fortschritts eines Sprints unterhalten. Die Diskussion war sehr interessant, daher möchte ich die Essenz daraus in diesem Artikel teilen.

Ausgangspunkt war dass in einem Scrum-Projekt gemessen werden sollte, ob das Sprint-Ziel in Gefahr ist. Die altbekannte These „Was ich nicht messen kann, kann ich auch nicht managen“ war dabei die Leitidee. Diese Leitidee teile ich im Prinzip. Einen Burndown Chart während eines Sprints halte ich aber nicht für hilfreich, insbesondere nicht, um eine Gefährdung des Sprint-Zieles abzulesen.

Warum nicht?

Messen kann man in Scrum, ob eine Story fertig ist. Fertig ist sie, wenn sie der Definition of Done genügt und der Product Owner sie sich in einem Review angeschaut und akzeptiert hat. Der Review durch den Product Owner erfolgt üblicherweise im Sprint Review am Ende eines Sprints. Natürlich könnte man das auch während des Sprints machen, aber im Sprint soll das Team möglichst ungestört arbeiten.
Das Sprint-Ziel ist erreicht, wenn alle Stories, auf die sich das Team committed hat, am Ende des Sprints der Definition of Done genügen und vom Product Owner akzeptiert sind.

Wie könnte mir hierbei ein Burndown Chart helfen?
Dazu muss man mehrere Überlegungen anstellen.
Zunächst benötigt man eine Metrik, die eine Messung möglich macht. Eine einfache Metrik wäre die Anzahl der Tasks am Scrum Board. Je mehr Tasks erledigt sind, desto näher rückt man dem Sprint-Ziel.
Das ist aber trügerisch, weil zum einen Tasks unterschiedliches Risiko in sich tragen und nicht in beliebiger Reihenfolge ausführbar sind. Sie sind nicht beliebig austauschbar und eine Story ist nicht zu 80% fertig, wenn 80% der Tasks erledigt sind. Wie bereits gesagt: Eine Story ist erst fertig, wenn sie der Definition of Done genügt und der Product Owner sie akzeptiert.
Das diese Metrik nicht valide ist, lässt sich auch noch anders begründen:
Die These Wenn von 50 Tasks 40 beendet sind, ist das Sprint-Ziel zu 80% erreicht. Die Dauer des Sprints ist aber vielleicht schon zu 90% vorüber. Laut der Metrik ist das Sprint-Ziel gefährdet. Erfreulicherweise dauern aber die letzten 10 Tasks nur noch 5% der Sprint-Zeit und das Sprint-Ziel wird erreicht. Die Metrik hat da aber unter Umständen bereits den Product Owner und weitere Stakeholder in Alarmbereitschaft versetzt.
So wird es also nicht funktionieren.

Nun kam das Argument, dass man eben nicht die Tasks, sondern die Stundenschätzungen für die einzelnen Tasks als Basis für die Metrik nehmen sollte. Nun muss ich sagen, dass ich das Schätzen von Stunden auf Tasks Teams in der Regel recht schnell abgewöhne (worüber ich demnächst sicherlich auch einen Artikel schreiben werde), so dass ich darüber etwas länger nachdenken musste. Letztendlich ist das Problem aber das gleiche wie bei der bloßen Betrachtung der Anzahl der Tasks. Die Stunden pro Task sind geschätzt. Hat man sich am Anfang etwas überschätzt, also die Tasks kleiner geschätzt als tatsächlich an Zeit benötigt wird, schrillt vielleicht nach zwei Tagen die Alarmglocke, obwohl noch viel Zeit ist. Das wäre nur lästig, nicht tragisch. Wesentlich ungünstiger wäre es, wenn die Tasks am Ende eines Sprints mehr Zeit benötigten, als geschätzt. Dann wird das Sprint-Ziel verfehlt, obwohl die ganze Zeit alle Zeichen auf Grün standen.

Es gab dann noch Ideen, die Tasks mit Risiko-Faktoren zu versehen und Gantt-Diagramme einzusetzen. Das halte ich aber in einem agilen Projekt für grundlegend falsch. Hier würde das Verwalten der Aufgaben mehr Zeit kosten, als dem Team für die Arbeit am Projekt bleibt 😉

Letztendlich ist es egal, wie man es dreht, ein Sprint-Burndown sagt dem Team nichts und dem Product Owner auch nicht hinsichtlich der Frage, ob das Sprint-Ziel erreicht wird. Erst der Sprint Review sagt, ob man das Ziel erreicht hat ober nicht.

Da ich lange für Automobilhersteller gearbeitet habe, hier noch ein Vergleich:
Sprint-Burndowns sind der Versuch mit einem Auto-Tacho zu messen, wie viele Zentimeter man zurückgelegt hat.
Das klappt nicht, denn der Tacho gibt das einfach nicht her, weil er nur in 100-Meter-Schritten misst. 🙂

4 Kommentare bei „Burndown Charts im Sprint?

  1. Einverstanden bin ich mit der Kernaussage, dass ein Burndown Chart nicht für das Messen des Sprint Fortschritts durch das Management missbraucht werden sollte. Nach meiner Erfahrung kann ein Task Burndown Chart – richtig verwendet – dem Team selbst sehr wertvolle Dienste leisten: An der Wand stets sichtbar gibt es eine Indikation, ob geplante Tasks fortlaufend geschlossen werden. Nachträglich hinzu kommende, bei der Planung nicht bedachte Tasks werden als senkrechte Linie nach oben visualisiert und auftretende Impediments werden direkt an die Burndown Kurve geschrieben. So entsteht eine plakative Historie des Sprintverlaufs, anhand derer das Team während den Sprints und in der Retrospektive Verbesserungsaktionen ableiten kann.

    1. Hallo Till,

      danke für Deinen Kommentar!
      Der Artikel bezieht sich ja auch ausschließlich auf die Fragestellung, ob das „Messen“ mit dem Burndown Chart sinnvoll ist oder nicht.
      Über Burndown Chart Pattern und wie man sie in der Retrospektive sinnvoll einsetzen kann, werde ich in den nächsten Wochen noch einen Artikel schreiben.

  2. Interessant an der Betrachtung finde ich, dass das eigentliche Problem völlig unabhängig davon ist, ob ich mich in der agilen Softwareentwicklung befinde oder im klassischen V-Modell oder beim Backen von 10000 Brötchen. Der Manager will immer und zu jeder Zeit einen möglichst genauen und aussagekräftigen Status zum Fortschritt der Arbeiten haben. Das wird umso häufiger hinterfragt, wenn das Projekt gefühlt oder tatsächlich zu langsam vorankommt – was wiederum zum Ende der ursprünglich geplanten Projektlaufzeit immer öfter der Fall ist. Leider wird dadurch das Projekt zum Ende hin immer mehr mit Management-Anforderungen überfrachtet, die selten einen zusätzlichen Nutzen bringen, sondern dem Projekt eher schaden. Deshalb ist meine Empfehlung: im Sprint Vertrauen zum Team haben. Wird das Sprint-Ziel häufiger nicht erreicht, müssen die Ursachen gefunden werden. Das wird aber durch ein irgendwie geartetes noch kleinteiligeres Fortschrittsreporting sicher nicht erreicht.

  3. Ich würde sagen,
    du hast Burndown charts anders als ich verstanden.
    Ich sehe einen Burndown chart nicht als eine strikte Metrik sondern einen Idikator.
    Geht die Kurve nicht nach unten, oder gar nach oben ist etwas verkehrt.

    Deinen Punkt den du mit Stories können zu 80% umgesetzt sein, ja dann sind sie eben nicht DONE, dann sollte vielleicht diese Story DONE werden bevor noch eine angefangen wird.

    Burndown chart kann auch in die umgekehrte richtung indizieren,
    sind Stories zu schnell DONE waren sie evtl nicht umfangreich genug oder sind doch nicht wirklich DONE

    Wenn stories erst im Review „voll done“ setzen sollte man den Burndown chart auf „Ready for Review“ ansetzen.
    Aus Sprint betrachtung ist eine Story DONE wenn sie ready for review ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.