Das Burndownchart: Erfolgsmesser und Analysewerkzeug

In einem Projekt saßen wir mit sechs ScrumMastern in einer Runde und diskutierten den Nutzen und das Führen eines Burndowncharts.Es handelte sich um ein Projekt mit sechs Scrum-Teams und interessant dabei war, dass es erhebliche Unterschiede und Eigenkreationen in der Ausführung gab, die wir näher betrachteten. Einige ScrumMaster führten ihr Burndownchart auf Task-Ebene, einige auf Story-Ebene, beklagten aber, dass häufig kein Erfolg zu sehen sei und der Graph immer erst zum Ende eines Sprints abfalle. Es entstand eine spannende Diskussion mit fruchtbarem Ende.Betrachten wir die beiden Beispiele näher und machen wir uns bewusst, was uns das Burndownchart zunächst einmal sagen soll:Auf der horizontalen Achse finden wir die Sprinttage. Auf der vertikalen Achse finden wir die Anzahl der noch zu bearbeitenden Storypoints des aktuellen Sprints, die im Estimation Meeting geschätzt und im folgenden Sprint Planning 1 vom Entwicklungsteam committet, sprich als lieferbar zugesagt wurden.Pro abgeschlossener Story kann im Sprint nun markiert werden, wie viele Storypoints noch zu bearbeiten sind. Im Normalfall ergibt sich so über den Sprint ein treppenförmiger Graph mit Abwärtstrend, der zum Sprintende oder auch schon vorher die horizontale Achse treffen sollte. Die Teammitglieder können so ihren Fortschritt auf einfache Art und Weise visualisieren.Wie kann es nun im oben genannten Beispiel dazu kommen, dass sich der Graph in gewissen Fällen parallel zur horizontalen Achse bewegt und erst am Ende eines Sprints einen steilen Abfall nach unten macht, man also meinen könnte, es gäbe keinen Fortschritt?First things first lautet doch die Devise. Wir arbeiten der Priorisierung nach eine Story nach der anderen ab. So ist die sinnige Idee.In vielen Fällen wird jedoch über den gesamten Sprint gleichzeitig an mehreren Stories gearbeitet, was eigentlich nicht vorgesehen ist. Dadurch werden die Stories erst spät oder ganz zum Sprint-Ende abgeschlossen und man kann erst hier einen Erfolg ersichtlich machen. Auf die Frage, warum an mehreren Stories gearbeitet werde, sagte eine ScrumMasterin zu mir, es ginge nicht anders, da die Stories ja voneinander abhängig seien.Das gibt einen Hinweis darauf, dass die Stories nicht der Abhängigkeit entsprechend im Backlog standen. Natürlich muss eine Story, die von einer anderen abhängig ist, weiter unten im Backlog stehen. Wir sehen also, dass das Burndownchart auch Analysezwecken dienen kann. In unserem Beispiel könnten wir also mit dem verantwortlichen Product Owner die Priorisierung des von ihm geführten Backlogs besprechen.Ein zweiter, typischer Grund für ein Burndownchart, das erst zum Sprint-Ende abfällt, kann die Tatsache sein, dass eine/die Story/s schlichtweg so groß ist/sind, dass man den ganzen oder fast den ganzen Sprint an ihr/ihnen arbeitet. Das Risiko, nicht fertig zu werden, ist also zu groß. Wir können somit aus der Analyse des Charts lernen, dass unser Product Owner die Stories kleiner schneiden muss.In beiden Beispielen zeigt sich also, dass das Burndownchart ein wunderbarer Indikator für die Priorisierung und Schätzung bzw die Größe der Stories ist.Was bewegte nun den ScrumMaster, der das Burndownchart auf Taskebene führte? Auf diese Frage berichtete er, dass er täglich einen Erfolg sehen möchte, um mit gutem Gefühl nachhause zu gehen. Es störe ihn nämlich genau der zuerst beschriebene Fall, dass der Erfolg häufig gar nicht oder erst sehr spät zu sehen sei. Die Tatsache, dass er den Erfolg doch an den sich horizontal über das Taskboard bewegenden Tasks sehen kann und unsere Diskussion überzeugten ihn letztlich, das Burndownchart ebenso auf Story-Ebene zu führen. Tun wir dies nicht, stehen uns nämlich die beschriebenen Analysemöglichkeiten nicht zur Verfügung, zumal den Tasks ja keine Storypoints zugeordnet sind. Worauf sollte man also das Führen des Burndownchart dann basieren lassen?In der beschriebenen Runde mit unseren ScrumMastern beschlossen wir, dass die Charts gesammelt an einer Wand im Büro aufgehängt werden, um so den Erfolg jedes einzelnen Teams transparent für alle zu machen und somit einen positiven Synergie- und Lerneffekt enstehen zu lassen.Wenn wir nun zusammenfassen, sehen wir, welchen großen Sinn es macht, das Burndownchart auf Story-Ebene zu führen und dass es viel mehr ist, als nur eine visualisierte Information zum Fortschritt des aktuellen Sprints.