Burn Down Chart
Das Burn Down Chart ist ein Instrument, das meist in der Scrum-Methode zum Einsatz kommt, um einen Überblick über die geleistete bzw. noch anstehende Arbeit zu bekommen. Es stellt in visualisierter Form dar, wie viel Arbeit im Zuge des aktuellen Projektes noch zu leisten ist, geht aber darüber hinaus, weil es auch Auskunft darüber gibt, wie schnell das Team arbeitet. Dadurch lässt sich analysieren, ob die Entwickler zu wenig oder zu viele Aufgaben wahrnehmen. Die aus dem Burn Down Chart gewonnenen Erkenntnisse fließen in die Planphase ein, um beispielsweise den nächsten Sprint in Angriff zu nehmen und eine angemessene Zeitspanne zu realisieren[1].
Allgemeine Informationen zum Thema
Vermehrt wird in der Software-Entwicklung die agile Herangehensweise favorisiert, besonders oft taucht dieser Begriff im Zusammenhang mit der Scrum-Methode auf. Scrum bietet zahlreiche Vorteile bei der Planung und Umsetzung von Projekten. Um den jeweiligen Fortschritt zu messen, kommt unter anderem das Burn Down Chart zum Einsatz. Somit kann eine Einschätzung erzielt werden, um die Entwicklung des Backlog-Items und die voraussichtliche Dauer zu beurteilen. Burn Down Charts können im Sprint Backlog und im Product Backlog genutzt werden.
Vorbereitung und Ablauf
Vor dem Burn Down Chart kommen die sogenannten Story Points. Sie werden vor dem Beginn des Sprints erstellt und geben Auskunft über die Aufwandsabschätzungen mittels durch das Team ermittelter Backlog Items. Die Zeitangabe der Story Points kann in relativer oder echter Zeitangabe erfolgen. Die Summe der in den Backlog Items ermittelten Aufwände ist der Initial Sprint Effort, der gleichbleibend ist, so lange sich weder die Dauer des Sprints noch die Verfügbarkeit der Teammitglieder ändert. Im Zuge des ersten Sprints wird der ideale Wert nach und nach ermittelt.
Während der Sprint andauert, kommt es zu Daily Scrum Meetings, in denen jedes Teammitglied berichtet, wie der eigene, aktuelle Status aussieht. Dies geschieht entweder durch relative Werte (also in prozentualen Angaben wie etwa: 50 Prozent erledigt) oder durch absolute Werte (also zum Beispiel mit der Angabe: 4 Stunden Restdauer). Die Summe der Remaining Efforts für alle Sprint Backlog Items wird als Remaining Sprint Effort bezeichnet. Dieser Wert wird nun täglich in das Burn Down Chart eingetragen, das ein Diagramm darstellt.
Wenn man das Burn Down Chart erstellt, wie es vorgesehen ist, bekommt man sehr präzise Aussagen, die bis auf die Stunde genau sein können. Einziger Nachteil bei diesem Vorgehen ist die Gefahr, dass sich die Entwickler verschätzen und am Ende deutlich wird, dass der gewählte Ansatz so doch nicht verwirklichbar ist. Am Ende jedoch kann man sich darauf verlassen, dass die Einträge im Burn Down Chart Diagramm richtig sind, denn dort werden keine Schätzungen eingetragen, sondern faktisch erzielte Erfolge[2].
Burn Down Charts versus Burn up Charts
Das Prinzip der Burn Down Charts hat durchaus Kritiker. Denn bei der Praxis des Burn Down Charts liegt der Fokus im „Abbrennen“ (im Sinne von „Burn“) der Arbeiten, die noch bevorstehen. Die bereits erbrachte Leistung dagegen spielt kaum eine Rolle. Zudem wird als problematisch erachtet, dass bei der Arbeit mit Charts in Form von Flipcharts die Verlaufslinie nach oben oder unten verschoben werde, was sich in der Praxis als schwierig erweise.
Als Alternative wird oft die Burn Up Darstellung gesehen. Sie ist eine 180-Grad Spiegelung der Burn Down Darstellung und zeigt die bisher erbrachte Arbeit statt die noch bevorstehende anzuzeigen. Die Verlaufslinie startet bei dieser Burn Up Darstellung links unten und endet rechts oben, was eine Erleichterung und Vereinfachung darstellen soll[3].
Ein weiterer Kritikpunkt bei Burn Down Charts geht aus der Annahme hervor, dass sich über die ganze Laufzeit des Projekts der Ressourceneinsatz nicht verändert. Das ist aber nicht immer möglich und beeinflusst entsprechend die Planung. Man kann darauf reagieren, indem man das Diagramm ändert, also die Ideallinie von der geraden Linie abweichen lässt. Stehen also temporär weniger Ressourcen zur Verfügung, wird eine geringere Abarbeitung geplant, im umgekehrten Fall eine größere. Falls es zu personellen Ausfällen kommt – beispielsweise durch Urlaub oder Krankheit – können Pseudo-Projekte angelegt werden, die den Ausfall der Mitarbeiter berücksichtigen und aufzeigen. Am Ende muss allerdings in der Summe (also der Stapelung) wieder eine Ideallinie mit einem linearen Verlauf stehen.
Wie bereits weiter oben erwähnt, hängt die Frage nach der Übereinstimmung von Planung und Realisierung davon ab, wie genau der Aufwand vom Team eingeschätzt wurde. Wird dieser unter- oder überschätzt, weicht das Ergebnis ab. Zur Verhinderung dieses Problems kann ein Effizienzfaktor eingeführt werden, mit dem der im Vorfeld angenommene Aufwand multipliziert wird, bevor es zur Zeichnung der Ideallinie kommt[4].
Bedeutung für das Development
Die Frage, ob es sinnvoller ist, Burn Down Charts oder Burn Up Charts zu verwenden, ist objektiv nicht beantwortbar, die Entscheidung ist eine individuelle. Zuweilen spielt auch ein psychologischer Effekt eine Rolle, also dahingehend, ob es der Arbeit dienlicher ist, wenn aufgezeigt wird, was bereits an Aufgabenstellungen erledigt wurde oder was noch zu erledigen ist. Die Frage, inwiefern man in laufende Projekte bei Veränderungen eingreifen kann und ob dies besser mit Burn Down oder Burn Up funktioniert, spielt ebenfalls bei der Wahl des passenden Charts eine Rolle. Ein gänzlicher Verzicht auf Charts ist jedoch keinesfalls sinnvoll.
Einzelnachweise
- ↑ Was ist ein Burn Down Chart microtool.de. Abgerufen am 15.12.2017
- ↑ Burn Down Chart thewebhatesme.com. Abgerufen am 15.12.2017
- ↑ Scrum ohne murcS: Agile Projektmanagementpraxis korn.ch. Abgerufen am 15.12.2017
- ↑ Burn Down Chart Kritik und Modifikationen de.wikipedia.org. Abgerufen am 15.12.2017