In letzter Zeit sehe ich immer mehr Beispiele wie, aus meiner Sicht eines der wichtigsten Werkzeuge der agilen Produktentwicklung, das Releaseburndown, vernachlässigt wird. In diesem Post spreche ich zunächst darüber was es ist und wozu man es braucht. Am Ende steht ein Link zu einer Releaseburndown Vorlage (Google-Spreadsheet), die jeder kopieren und selbst verwenden kann. Also erst einmal: Warum brauchen wir ein Release-Burndown?
In agiler Produktentwicklung verabschieden wir uns von definierter Prozesskontrolle und setzen statt dessen auf die empirische Prozesskontrolle. Die Gründe dafür stehen hier im Artikel Quellen von Veränderung und Unsicherheit in der Produktentwicklung. Und was agile Produktentwicklung bedeutet ist in Teilen hier erklärt (und braucht noch einen gesonderten Post).
Konkret bedeutet es, dass wir nicht vorher sagen, wie lange etwas dauert. Nicht weil wir es nicht wollen, sondern weil wir ehrlich sind und wissen, dass wir es nicht können. Das ist ja einer der Gründe für die ganze Agile Vorgehensweise. Das stellt aber eine Menge Stakeholder vor große Probleme.
Es gibt viele Dinge in einem Unternehmen, die von der Produktentwicklung zeitlich abhängig sind. PR-/Marketingkampagnen zum Beispiel brauchen Vorlaufzeit um geplant zu werden und man will sicher sein, dass die beworbene Funktionalität auch da ist. Es gibt auch viele andere Fälle in denen zeitliche Synchronisierung mit Akteuren außerhalb der Produktentwicklung wichtig wird. Und es gibt darauf eine gute Antwort – den Release-Burndown.
Mit Release ist hier die Fertigstellung eines Epics gemeint. (Die Zwischenergebnisse sollten natürlich so häufig möglich live gesetzt werden). Epics sind typischerweise zusammenhängende Funktionalitäten, die einem Nutzer größeren Mehrwert liefern, also zum Beispiel beworben werden könnten. Wie wissen wir also, wann ein größeres Epic geliefert wird? Nun, das tun wir nicht. Aber wir können es mit ziemlich hoher Genauigkeit vorhersagen.
Am Anfang des Epics schätzen wir die gesamte Arbeit. Das passiert eher ungenau, wir haben schließlich sehr wenig Erfahrung mit dem Epic. So bekommen wir die erste initiale Schätzung für den Gesamtaufwand. Nach der ersten Iteration wurden einige kleine Teile dieses Epics fertig bearbeitet, also die Anzahl der gesamten Punkte im Epic reduziert. Zusätzlich kennen wir die Domäne nach dem ersten Sprint besser. Wir sehen Dinge, die wir vorher vielleicht übersehen haben und haben Risiken und Unbekannte reduziert. Dieser Informationsgewinn kann sich positiv oder negativ auf den Gesamtaufwand auswirken.
Am Ende jeder Iteration tragen wir den aktuellen Stand des übrig gebliebenen Gesamtaufwands in eine Tabelle ein. Wenn wir die Zahlen extrapolieren, können wir vorhersehen, wann das Epic wahrscheinlich fertiggestellt wird. So können wir schon nach 2-3 Iterationen sehen, ob es ein Problem mit einer erwartertenen Deadline geben wird.
Ich habe eine einfache Release-Burndown Google-Spreadsheet Vorlage gebaut, mit Hilfe derer man den extrapolierenden Graphen automatisch erstellt. Es gibt ihn dort auf Deutsch und Englisch (verschiedene Blätter des Spreadsheets). Die Vorlage erklärt noch einmal selbst, wie man sie nutzt.
Ich hoffe es ist nützlich. Ich bitte um Feedback, wenn ich an der Vorlage etwas verändern soll.
Und ein Tipp für alle Product Owner unter den Lesern. Wenn ihr euer Team dazu motivieren wollt, fokussierter zu arbeiten: Zeigt ihnen wo ihr steht mit einem Release-Burndown, am besten in jedem Sprint Review.