Kategorien
Burn-Down-Chart
Bei der Software-Entwicklung findet die Agile Bewegung immer mehr Anhänger. Insbesondere Scrum erfreut sich großer Beliebtheit. Dies liegt sicherlich unter anderem auch daran, dass Scrum ein Planungsverfahren ist, das eine sehr gute Fortschritt-Transparenz bietet.Das wohl beste Werkzeug zur Messung des Fortschrittes ist der Burn-down-Chart. Damit kann abgeschätzt werden, wie lange die Entwicklung der Backlog Items noch dauert. Angewandt werden kann der Chart sowohl auf das Product Backlog, als auch auf das Sprint Backlog.
Ich möchte hier zwei verschiedene Arten des Burn-down-Charts vorstellen:
- Auf „Remaining Effort Estimations“ basierend
- Auf „Completed Backlog Items“ basierend
Auf „Remaining Effort Estimations“ basierend
Bevor der Sprint begonnen hat, ist es die Aufgabe des Teams, anstehende Backlog Items mit Aufwandsabschätzungen zu versehen. Dies kann in sogenannten „Story Points“, einer relativen Zeitangabe, oder in einer echten Zeiteinheit erfolgen.
Die Summe der Aufwände aller Backlog Items ergibt den „Initial Sprint Effort“. Ändert sich weder die Sprint-Dauer noch die Verfügbarkeit der Teammitglieder, wird sich dieser Wert von Sprint zu Sprint kaum unterscheiden. Bei den ersten Sprints nach der Einführung von Scrum muss der ideale Wert für die Menge an Arbeit, die das Team in einem Sprint leisten kann, jedoch erst gefunden werden.
Während des Sprints werden Daily Scrum Meetings durchgeführt, bei denen jedes Teammitglied seinen aktuellen Status berichtet. Dies kann in relativen (50% abgeschlossen) oder absoluten Werte (Restdauer: 4 Stunden) mitgeteilt werden. Summiert man die Remaining Efforts für alle Sprint Backlog Items auf, erhält man dadurch den „Remaining Sprint Effort“.
Trägt man diesen Wert täglich in ein Diagram ein, erhält man einen Burn-down-Chart.
Die rote Kurve stellt die Abschätzung der Entwickler dar. In der Regel fällt die Kurve von Tag zu Tag ab. Sie kann, wie am 6. Tag angedeutet, auch steigen. Ein ansteigender Restaufwand kann entweder von einem Rescoping der Sprint-Ziele oder von Hindernissen bei der Entwicklung kommen.
Verbindet man die aktuelle und die initiale Restzeit zu einer Geraden, erhält man eine Vorhersage darüber, wann die Features des Sprints abgeschlossen sind. Im oben dargestellten Diagramm fehlen nach den 14 Tagen beispielsweise noch 5 Stunden restliche Entwicklungszeit.
Auf „Completed Backlog Items“ basierend
Erstellt man einen Burn-down-Chart wie oben erklärt basierend auf Schätzungen von Entwicklern, erhält man sehr präzise Aussagen, die sogar stundengenau aussagen können, wie die Entwicklung voran geht.
Die Gefahr hierbei ist jedoch, dass sich Entwickler verschätzen können. Oft wird erst am Ende der Entwicklung klar, dass der gewählte Ansatz doch nicht so verwirklichbar ist.
Dabei stammt selbst von Scrum die Aussage, dass lediglich abgeschlossene Features als „fertig“ gesehen werden können. Der Burn-down-Chart basierend auf „Completed Backlog Items“ nimmt diese Ansicht genau.
Es wird initial die Anzahl der Features des Sprints gezählt. Beim Daily Scrum Meeting wird der verbleibende Aufwand durch die Anzahl der noch nicht abgeschlossenen Features berechnet. Nur wenn ein Feature abgeschlossen ist, macht sich dies im Burn-down-Chart bemerkbar.
Burn-down-Chart basierend auf completed features
Die Konsequenz ist, dass man sich auf die Aussagen dieses Diagramms tatsächlich verlassen kann, denn die hier aufgezeigten Erfolge sind keine Schätzungen. Die Voraussetzung, damit dieses Diagramm jedoch überhaupt Erkenntnisse bringen kann ist, dass die Sprint Backlog Items in einer sehr feinen Granularität gewählt werden. Dauert ein Sprint 14 Tage und enthält exakt so viele Backlog Items wie Teammitglieder, erkennt man beispielsweise bis zum Ende gar keinen Fortschritt. Möchte man Scrum jedoch sinnvoll anwenden, macht es ohnehin Sinn, die Granularität der Items klein zu halten. Ein oft empfohlener Zeitraum für ein Sprint Backlog Item ist ein Personen-Tag. Dadurch wird auch in diesem Diagramm der Fortschritt erkennbar und Probleme werden aufgedeckt.
Was jetzt?
Keiner der Ansätze klingt schlecht. Beide haben ihre Vorzüge und decken auch teilweise unterschiedliche Probleme auf. Was hindert einen daran, beide Werkzeuge zur Fortschrittsmessung einzusetzen? Sitzen Teammitglieder länger an Problemen, von denen sie denken, sie bald gelöst zu haben, deckt dies der auf completed features basierende Burn-down-Chart auf. Bei Entwicklungen, die etwas länger als erwartet dauern können, veranschaulicht der auf estimations basierende Burn-down-Chart trotzdem die Fortschritte.
Möchte man einen Burn-down-Chart über das komplette Product Backlog anfertigen, ist die Granularität der Sprint Backlog Items verhältnismäßig so gering, dass für vernünftige Vorhersagen sicherlich ein Completed-Feature Burn-down-Chart genügt.
Irgendwie wird nicht mehr so viel kommentiert, seitdem ich die RSS Feeds freigegben habe 🙁 Schade Schade.
Das ist ja schade zu hören, lebt ein Blog doch auch von seinen Kommentaren!
Evtl. die Inhalte doch besser im HTTP lassen und lediglich per RSS anteasern? Ich meine, die Leute die offline lesen wollen können sich ja auch die Seite downloaden.
Oder den Leuten die möglichkeit geben, selber Comments per Email machen zu können? Ich glaube im Opera-Feed-Reader geht das, sodass hier beim lesen kommentiert werden kann und wenn man wieder online ist, der Kommentar auch losgeschickt werden kann.
Sehr interessanter Artikel, Timo.
Die Graphen werden ja sicherlich aus den digital erfassten Sprint Backlogs erzeugt.
Gibt es hier Werkzeuge die man empfehlen kann?
Grüße,
Adrian
Interessanter Artikel 🙂
Kommt mehr im Bereich Projektmanagement??
Gruß
@Kevin, ja es wird noch mehr zum Thema Projektmanagement geben. Die nächsten Tage werden wir auch einen neuen Autor begrüßen, der sich speziell mit diesem Thema verfasst. Natürlich werden Timo und ich auch weiter schreiben.
@Adrian: Danke, es ist auch ein sehr spannendes Thema… Speziell zur Erzeugung des BurnDown-Graphen wird es nächste Woche noch einen Eintrag geben.
@Timo, Super, bin gespannt 🙂
Also ich seh am Item Burndown Chart gegenüber dem Storypoint Burndown Chart keinen Vorteil. Wenn die Items zu groß sind, macht das an der Kurve keinen Unterschied. Auch sonst macht es nicht viel Unterschied, was nur anders ist, sind die Zahlen auf der Y-Achse.
Ich finde das Storypoint Chart sogar besser, da es mir genauer zeigt, wie viel Arbeit noch zu tun ist. Items sind unterschiedlich groß, das ist auf dem Item Chart überhaupt nicht sichtbar.
Weiterhin finde ich übrigens Items, die nur 1 Tag lang dauern ZU klein. Klar, solche Items gibt es immer wieder (z.B. neue Grafiken einbinden oder weiß der Geier was), aber 1 Tag lange Items sind doch eher unrealistisch. Vor allem aber läuft man dann Gefahr, dass der Product Owner bereits Arbeit erledigt, die tatsächlich aber erst in Sprint Planning 2 gemacht werden sollte: Design. Wenn ich meine Items in 1-Tages-Items aufbreche, laufe ich doch Gefahr, dass die Items bereits genau besagen, wie etwas implementiert werden soll. Tasks, die zu einem Item gehören, sollten nicht länger als 1 Tag dauern, das definitiv, aber nicht Items.
Die Grafiken sprengen scheinbar das „neue“ Design, vllt. solltest du die etwas verkleinern.
wär ja dafür das jede woche mindestens einmal ein PM/Scrum Artikel gepostet wird
oder doch vielleicht pmhatesme.com ? 🙂
@Timo Vielleicht noch ein Wort zur Größe der Backlog-Items? Hättest erwähnen können, dass die vorgeschlagene Größe bei Scrum maximal 4 Stunden pro Item ist.
Kommt noch der Vergleich zu den Burnup-Charts? Wie zeichnest du die Linie für die ungeplanten Aufgaben im Burndown-Chart ein: als Burnup oder als Burndown vom Maximalwert?