Was ist ein BurnUp Chart?

Der BurnUp Chart ist eine visuelle Gegenüberstellung der bereits erledigten Arbeit und der noch offenen Tätigkeiten eines agilen Teams gesehen über die Laufzeit eines Projektes. Er dient zur Prognose und Planung agiler Umsetzungen.

Wie erstellt man einen BurnUp Chart?

Im Grunde ist es ganz einfach. Die X-Achse stellt die Zeit dar, meistens in Sprints. Die Y-Achse stellt den zu erbringenden Aufwand dar, meistens in Story Points. Bei jedem Sprint wird der tatsächlich geleistete Aufwand eingetragen, die Punkte verbunden und die dadurch entstehende Linie mit einer Prognose basierend auf der durchschnittlichen Team Velocity ergänzt.

Wie unterscheiden sich BurnUp und BurnDown Chart?

Der BurnUp Chart ist die umgekehrte Darstellung des klassischen BurnDown Charts. Während der BurnDown zum Tracken der offenen Aufwände einer Iteration genutzt wird, nutzt man den BurnUp meist zum Planen eines Releases.

Die Aufwände einer Iteration sind im Normalfall fixiert. Der Scope der Iteration verändert sich also nicht. Mann kann eine Soll-Linie für die Abarbeitung einzeichnen und diese mit der tatsächlichen Abarbeitung vergleichen und entsprechend reagieren. Auf ein ganzes Release gesehen, verändert sich der Scope im agilen Vorgehen per Definition! Feedback und Änderungen der Anforderungen sind willkommen, es können also jeder Zeit Features dazu kommen oder wegfallen. Im BurnDown Chart vermischen sich Scope und Abarbeitung. Im BurnUp Chart sind diese klarer voneinander getrennt und lassen so leichter Rückschlüsse auf Fortschritt und Trends zu.

Die Abbildung zeigt, dass im Extremfall (z. B. paralleler Anstieg zur Abarbeitung) nur schwer differenzierbar ist und ob das Problem bei der Abarbeitung oder bei den Anforderungen liegt.

Was nutzt ein BurnUp Chart?

Prognose von agilen Umsetzungen

Ich schreibe hier bewusst Prognose und nicht Planung von agilen Umsetzungen. Ich bin ein großer Fan von Planung, daher arbeite ich mit BurnUp Charts.

Projektplanung im klassischen Sinn ist im komplexen Umfeld oft nur schwer möglich. Darum werden agile Methoden bevorzugt. Was wir aber auf jeden Fall tun können, ist auf Basis des aktuellen Wissens eine Prognose abzugeben, wann ein Feature oder ein ganzes Release fertig sein wird. Auf Basis dieser Prognose kann ein Plan erstellt und wenn nötig gegengesteuert werden.

Wichtig ist nur, immer im Hinterkopf zu behalten, dass der Plan nicht in Stein gemeißelt ist. Daher sollte der BurnUp kontinuierlich nach jeder Iteration gepflegt und der Plan entsprechend angepasst werden.

Quantitative Messung des Ist-Standes

Will man einen validen BurnUp Chart erstellen, braucht es aktuelle Daten. Hier liegt auch schon die größte Schwierigkeit!

Woher soll man wissen, wie viele Story Points für ein großes Release noch offen sind? Ich möchte mich in diesem Artikel nicht im Detail mit dieser Frage beschäftigen, aber ganz ehrlich, mich würde es (meistens) nervös machen, nicht zu wissen wie viel noch offen ist und wo wir damit raus kommen.

Wenn es dir nicht so geht, dann arbeitest du entweder in einem wirklich coolen Umfeld (dazu noch mehr zum Schluss) oder du wirst bald ein Problem haben und an mich denken ;-)

Datenerfassung richtig gemacht

Aus dem vorigen Punkt ergibt sich automatisch die Notwendigkeit, Daten sauber und kontinuierlich zu erfassen und sich bewusst mit diesen zu beschäftigen.

Die Team Velocity ist hier meistens sehr schnell gemessen. Wieder ist der Scope die Herausforderung. Dort entsteht sofort der Bedarf, nach einem sauber gepflegten, geschätzten Backlog und einem Bewusstsein für Aufwände abseits der aktuellen Entwicklung.

Die Zeit sich damit zu beschäftigen ist auf keinen Fall verschwendet!

Klare und verständlicher Visualisierung des IST-Standes

Einer der ausschlaggebenden Gründe, wieso ich BurnUps gerne nutze ist ihre hohe Verständlichkeit.

Am Ende des Tages kann auf zwei Linien reduziert werden. Die Arbeit die noch getan werden muss und die Prognose wie Arbeit abgearbeitet wird. Wo diese beiden Linien sich treffen, dort sind wir 'fertig'.

Bei so manchem Projekt-Reporting musste ich erleben, dass reine Zahlen bei meinem Gegenüber nicht gut angekommen sind. Selbst wenn, kommen oft Aussagen wie 'das müsst ihr schneller hinbekommen'. Der BurnUp war in solchen Situationen immer eine gute Diskussionsgrundlage, weil er die Fakten so darstellt, wie sie sind und im Grunde nur 3 Reaktionen zulässt: Scope reduzieren, Velocity steigern, Release Zeitpunkt überdenken.

Grundlage für Analysen

Je nachdem wie genau man die Daten erfasst, kann man diese auch für umfangreiche Analysen verwenden.

  • Wo sind Schätzungen stark abgewichen?
  • Wie schaut die Velocity bezogen auf ein bestimmtes Feature oder einen Komponenten aus?
  • Wie ist der Trend der Scope Steigerung?

... das geht jetzt schon über die notwendigen Daten hinaus, aber ich habe festgestellt, dass ich plötzlich eine umfangreiche Datenmenge hatte und die obigen Fragen damit in sehr kurzer Zeit beantworten konnte. In dem Zusammenhang habe ich oft erlebt, dass der Vorwurf im Raum steht, dass ein Team zu langsam entwickelt und sich ein Vorhaben dadurch verzögern würde. Sehr oft ist es aber so, dass Teams konstant entwickeln, aber ständig neue Dinge dazu kommen und dadurch die Verzögerung entsteht.

Es ist vollkommen normal, ja sogar gut, dass Dinge dazu kommen. Wir wollen Feedback einarbeiten und es ist meistens positiv, wenn man neue Dinge entdeckt, an die man vielleicht nicht gedacht hat. Andererseits benötigt es ebenso eine offene Diskussion mit allen Beteiligten und das Treffen von entsprechenden Maßnahmen falls nötig.

Wobei muss man aufpassen beim BurnUp Chart?

Die richtige Zielgruppe und Interpretation

Auch, oder gerade weil der BurnUp vermeintlich so einfach zu verstehen ist, muss man aufpassen wie man damit umgeht.

Er zeigt die Fakten zum IST-Stand, diese können jedoch uninterpretiert leicht missverstanden werden. Bspw. wenn ein Backlog gut gefüllt ist, aber die Hälfte der Aufwände optional ist. Betrachtet man in diesem Fall nur den Schnittpunkt der Linien, muss man annehmen, dass ein Release Datum erst sehr spät erreicht werden kann, obwohl es schon viel früher möglich wäre. Meiner Erfahrung nach ist der BurnUp eine gute Grundlage für Diskussionen, sollte aber nicht unkommentiert nach außen getragen werden.

Hohe Aufwände vermeiden

Eine weitere Gefahr ist, dass die Erstellung und Pflege des BurnUps sehr viel Zeit in Anspruch nimmt. Der Hauptgrund dafür ist meistens ein unsauberer Backlog.

Wenn dieser gut strukturiert und gepflegt ist und nur die Arbeit enthält, die auch tatschlich relevant ist, dann sollte der Aufwand nicht mehr als 1-2 Stunden pro Sprint betragen.

Auch die Grobschätzung für nicht ausreichend detailliert geplante Aufwände kann sehr mühsam gestaltet werden. Man muss aufpassen, dass man hier nicht unnötig Zeit investiert für eine Illusion von Planungs-Sicherheit. Schätzungen sind immer ungenau, Methoden wie Magic Estimation oder die Verwendung des Durchschnittes an Story Points ist zu einem frühen Zeitpunkt gleichermaßen genau oder ungenau wie stundenlage Estimation Meetings mit 'Experten'.

Vergessen von Aufwänden

Auch wenn du jetzt vielleicht schmunzelst, weil der Punkt eh klar ist... man schätzt viel zu oft nur die reinen Entwicklungsaufwände der Features und blendet vieles drum herum aus. Hier muss man sich immer ins Bewusstsein rufen, was man abbildet und was nicht und es dann auch durchziehen.

Ein oft gesehener Fehler ist die Prognose mit 'zu viel' Fokus anzusetzen. 100% Velocity auf ein Feature zu planen klingt natürlich super, aber in der Realität werden andere Aufwände wie Bugs, Vorbereitungen, oder kleine Änderungen dazu kommen. Es wichtig, im ganzen Team und bei den Auftraggebern ein Bewusstsein für diese Vermischung zu schaffen.

Aufpassen muss man bezüglich des Trends mit dem der Scope steigt. Man neigt schnell dazu anzunehmen, dass der Scope jetzt aber wirklich fix ist und nichts mehr dazu kommen wird. Beobachte den Scope aktiv und bewusst und frage dich immer, warum er plötzlich aufhören sollte zu steigen. Ich ergänze in solchen Fällen gerne den BurnUp Chart mit einer Trend Prognose, die die durchschnittliche Steigerung darstellt. Der Effekt kann extrem ernüchternd sein, wenn man den neuen Schnittpunkt der Linien sieht.

Tipps zur Verwendung des BurnUp Charts

Umgang mit verschiedenen Zielen

In einem kontinuierlichen Entwicklungsprozess macht eine Scope Linie eigentlich keinen Sinn. Der Backlog wächst kontinuierlich mit.

Eventuell brauchst du bei diesem Grad an Agilität keinen BurnUp Chart mehr, weil dein Team so eingespielt ist und so schnell liefern kann, dass es vollkommen ausreicht, den Backlog für die Planung heranzuziehen. Falls du doch einen erstellst, kannst du mehrere Scope Linien nutzen um verschiedene Epics oder Releases darzustellen.

Von einzelnen, unabhängigen BurnUps rate ich an dieser Stelle ab. Gerade in einer kontinuierlichen Entwicklung werden Vorbereitungsaufwände für die nächste Initiative entstehen. Trennt man hier zu hart kann es leicht zu Fehleinschätzungen kommen.

BurnUp in Excel :-D

Das klingt jetzt soooo falsch, aber ich mache es trotzdem, aus mehreren Gründen.

Der Hauptgrund ist, dass ich gerne jede einzelne Zahl in die Hand nehme und kurz überlege, ob sie so stimmen kann und was sie bedeutet. Ich will mich bewusst damit beschäftigen und nicht einfach einen Knopf drücken... weil, und das ist auch schon der zweite Punkt, ich habe einfach noch kein Tool gefunden bei dem ich einen 100% nachvollziehbaren und verlässlichen BurnUp mit geringem Aufwand bekommen habe. Daher bleibe ich bei meinem Excel, da verstehe ich was passiert und habe viel Flexibilität, um neue Dinge zu ergänzen oder Experimente zu machen.

Auf keinen Fall Zahlen beschönigen!

Die Fakten sind wie sie sind und man sollte sie nüchtern betrachten und seriös damit umgehen. Als Scrum Master kann es auch schon mal schmerzen, wenn die Velocity sinkt und die Prognosen sich verändern. Dies dem Kunden gegnüber zu beschönigen macht keinen Sinn und wird dem Vertrauen langfristig schaden. In einer partnerschaftlichen Beziehung mit einem Kunden muss es möglich sein, gemeinsam mit allen Situationen umzugehen!

Typische Entwicklungen eines BurnUp Charts

Bilderbuch Verlauf

So in etwa sollte das aussehn... oder?

Ich bin nicht sicher, weil wenn dein Scope gar nicht steigt, dann hast du entweder sehr viel Zeit vorab in Requirements investiert oder du hast kein Feedback eingeholt. Oder du hast einfach alles richtig gemacht ;)

Annähernd paralleler Anstieg

Bedenklich ist, wenn dein Scope parallel zu Umsetzungsgeschwindigkeit steigt. Außer du bist in einer kontinuierlichen Entwicklung und trennst nicht zwischen verschiedenen Scopes. Wenn du im Wesentlichen ein Ziel hast und dem Ziel einfach nicht näher kommst, dann könntest du ein Problem haben.

Eventuell wurde vorab zu wenig Energie in die Vorbereitung gesteckt. Vor allem in sehr komplexen Umfeldern oder Landschaften mit viel Integrationsaufwand fährt man schnell auf Sicht und entdeckt permanent Neues, das man berücksichtigen muss. In diesem Fall kann es eine Zeit lang auch okay sein. Irgendwann sollte der Scope Anstieg abflachen. Helfen kann hier eine klare Trennung zwischen must haves und nice to haves und ein extremer Fokus auf Teilziele oder ein MVP.

Scope Reduktion kurz vor Release

Eine typischer Verlauf ist, dass gegen Ende der Scope doch noch etwas radikaler gekürzt wird, um ein angestrebtes Release-Datum einzuhalten. Wenn du gut priorisiert hast, treffen die Kürzungen nur die nice to haves, also alles gut ;)

Aufteilung in verschiedene Linien

Wie oben schon beschrieben, macht es oft Sinn, verschiedene Scope Linien zu verwenden. Das bringt Klarheit über verschiedene Ziele und fördert den Fokus, Ziele auch konsequent zu verfolgen. Man sollte es aber auch nicht übertreiben ;)

Normaler Verlauf

Im Normalfall wird dein Scope leicht ansteigen. Oft auch punktuell, weil bspw. ein User Test stattfindet und viel Feedback kommt oder man eine Arbeitspaket nicht mit berücksichtigt hat...

Ist ein BurnUp Chart überhaupt noch agil?

So viel Aufwand für agile Planung? Ist das denn wirklich gerechtfertigt?

Es kommt darauf an, in welchem Umfeld man unterwegs ist und wie hoch der agile Reifegrad dort ist. Zugegeben, den größten Bedarf an dieser Art der Darstellung und Planung hatte ich immer im klassischen Projektumfeld. Dort gibt es das berüchtigte Datum, dass dem Top-Management zugesagt wurde und den vermeintlich fixen Scope, der zu Projektbeginn niedergschrieben wurde. Hier kann ein BurnUp wirklich viel bewirken, Sachverhalte darstellen und als wunderbare Diskussionsgrundlage dienen.

In kleinen Unternehmen oder Start-Ups, in denen ohnehin das nächstwichtigste Feature im Vordergrund steht, wird ein BurnUp wahrscheinlich weniger effektiv sein. Egal in welchem Umfeld, planen ist auch im agilen Vorgehen wichtig und der BurnUp kann dabei helfen. Ob er agil ist oder nicht entscheidet wohl der individuelle Bedarf, der Nutzen und der Aufwand der dafür betrieben wird.

Fazit

Der BurnUp Chart war und ist für mich immer ein gutes Mittel, um im agilen Umfeld zu prognostizieren und zu planen. Er ist ein Analyse-Werzkzeug, ein großartige Diskussionsgrundlage und durch seine einfache Darstellung als solches auf verschiedensten Ebenen in einem Unternehmen gut nutzbar. Ob du ihn brauchst oder nicht hängt stark von deinem Umfeld ab.

Arbeitest du mit Projekten und hart kommunizierten Daten, dann wird er dir mehr nutzen, also in einer kontinuierlichen agilen Entwicklung. Wie so oft ist aber auch hier der Weg das Ziel. Rein sauberer BurnUp erzeugt einen starken Zugzwang auch einen sauberen Backlog zu pflegen und sich kontinuierlich mit den Daten zu befassen.

Wahrscheinlich ist das der eigentlich Mehrwert, und nicht das schöne Bildchen, dass am Ende in deiner Präsentation für das Management steht ;)