Marek ist seit anderthalb Jahren Product Owner. Sein Team baut an einer neuen Abrechnungsfunktion. Mit dem Vertrieb ist verabredet, dass die Sache Ende Oktober steht. Alle vierzehn Tage sitzt er mit drei Stakeholdern im Meeting und hört die Frage: Und, schaffen wir das?
Marek hat auf diese Frage keine gute Antwort. Er hat ein Gefühl und antwortet daraus, das Gefühl ändert sich aber von Sprint zu Sprint. Was Marek fehlt, ist ein Bild, das die Frage beantwortet, ohne dass er sie beantworten muss. Genau dafür gibt es Versions-Burndowns.
Ich (Anton hier) möchte in diesem Beitrag beschreiben, warum ich solche Burndowns nicht mehr aus Jira (oder anderen Ticketsystemen) erzeuge, obwohl es natürlich eine Funktion dafür hat und gebe Dir am Ende ein Werkzeug mit, das Du stattdessen nutzen kannst. Ich habe in meiner Karriere in drei verschiedenen Organisationen versucht mit Jira automatisiert einen Release-Burndown zu nutzen, und bin dreimal gescheitert.
Was dabei schiefgeht
Ein Versions-Burndown lebt lange. Zehn Sprints sind normal, bei zwei Wochen pro Sprint also zwanzig Wochen. In dieser Zeit kann sich am Ticketsystem irgendetwas ändern, was nicht in deiner Hand liegt und das wird deinen Burndown zerstören ohne dass es ein zurück gibt.
Die erste Organisation hatte über 1000 Mitarbeitende. Wir haben den „Epic Burndown“, so heißt das Feature in Jira um einen Versionsburndown zu erzeugen, fünf Monate lang benutzt, um mit Stakeholdern auf drei Ebenen über uns zu kommunizieren. Es lief gut. Dann war er aus dem Nichts kaputt. Ich habe monatelang gesucht und bis heute nicht herausgefunden, woran es lag. Ich weiß nur irgendeine Einstellung unserer Epics wurde geändert. Die wichtigsten Admins saßen auf einem anderen Kontinent und hatten ganz andere Themen. Als wir mit ihnen gesprochen haben, kamen wir nicht weiter.
Die zweite Organisation hatte 30 Menschen. Ich hatte den Product Owner eng begleitet und war für ihn im Jira für die Burndowns verantwortlich. Er hat seine Epic-Bezeichnungen geändert und leicht aufgeräumt. Danach war der Burndown unbrauchbar. Auch im dritten Fall wurde ähnelt dem zweiten, deshalb erzähle ich ihn nicht.
Zurück kommt man nicht. Die strukturelle Veränderung nimmt Dir den Blick in die Vergangenheit. Du könntest jeden Sprint einen Screenshot machen, aber ab dem Moment, in dem es passiert, baust Du alles von Hand neu auf. Das habe ich dreimal versucht und dreimal aufgegeben.
Jede weitere strukturelle Veränderung erzeugt dasselbe Problem wieder. Und in keinem der drei Fälle hat jemand einen Fehler gemacht. Admins haben ihre Arbeit gemacht, ein Product Owner hat seine Epics verfeinert. Das ist genau seine Aufgabe.
Warum mir das Burndown so wichtig ist
Der Wert eines Versions-Burndowns liegt darin, dass er lange steht. Marek zeigt seinen Stakeholdern zwanzig Wochen lang die Entwicklung im selben Bild. Sie gewöhnen sich daran. Mit der Zeit entsteht daraus Vertrauen und Verständnis.
In jedem Vorhaben tauchen mit der Zeit mehr Wünsche auf. Nur muss man darüber sprechen. Wenn Mareks Stakeholder vier Sprints hintereinander sehen, dass der Burndown nicht runter brennt, sondern nach oben, dann ist es leicht zu sagen: Wir nehmen zu viel auf, lasst uns gemeinsam entscheiden, was rausfällt.
Dafür muss das Bild einfach und leicht verständlich sein. Sobald die Zahlen kompliziert werden und längere Diskussionen entstehen, ist das Gespräch verloren. Dann reden alle über Datenherkunft statt über den Umfang der Version. Ein Burndown, den ein Außenstehender nicht in zehn Sekunden liest, erzeugt genau diese Diskussion.
Ein solches Werkzeug muss ein Informationsradiator (Begriff von Alistair Cockburn) sein. Es strahlt seine Information aus, man muss sie nicht suchen. Ein Versions Burndown aus einem Ticketsystem ist das Gegenteil. Man muss ihn aufmachen, man muss wissen, was gezählt wird und was nicht. Dass sich diese Systeme so frei konfigurieren lassen, ist ihre große Stärke und hier ihre Schwäche, denn niemand von außen weiß, wie sie eingestellt sind.
Wie ich es mache
Ich nehme einmal pro Sprint eine einzige Zahl auf: die Summe der Punkte, die für das Thema des Burndowns noch offen sind. Immer zum gleichen Zeitpunkt.
Früher habe ich das kurz vor dem Sprint Review gemacht. Heute würde ich direkt nach dem letzten Refinement raten, weil die Schätzwerte dort am frischesten sind. Wichtiger als die Wahl ist, dass es immer derselbe Zeitpunkt bleibt.
Wenn Du ein Ticketsystem hast, setzt Du dort einen Filter auf das Thema des Burndowns, und der liefert genau diese Zahl. Zählen musst Du also nicht.
Eine Voraussetzung gibt es. Alles, was zu dieser Deadline gehört, muss geschätzt sein. Die Schätzung darf grob sein, sie darf nur nicht „100+“ lauten, denn 100+ kann auch 1000 bedeuten. Das gilt unabhängig vom Werkzeug. Egal mit welcher Methode ich eine Deadline erreichen will, brauche ich zumindest irgendeine grobe Idee davon, wie viel Aufwand in der Arbeit vor dieser Deadline steckt. Ob das nun agil oder klassisch passiert.
Der berechtigte Einwand
Die Daten liegen doch längst im System. Warum sie noch einmal von Hand in eine Tabelle einpflegen?
Das ist ein guter Einwand. Meine Antwort ist eine Abwägung. Auf der einen Seite steht der Aufwand: eine Zahl pro Sprint. Auf der anderen Seite steht ein Werkzeug, das über Monate Vertrauen aufbaut, und das Risiko, dass es aus dem Nichts stirbt. Für mich steht das nicht im Verhältnis. Eine Zahl alle zwei Wochen ist billig.
Wie die Tabelle arbeitet
Ich habe mir über die Jahre immer wieder eigene Excels dafür gebaut. Hier ist eine allgemeinere Version davon.
Dass es Excel ist und keine App, ist wichtig. Eine App wäre wieder eine Blackbox. Excel zeigt jede Rechnung offen, die meisten Managerinnen und Manager können damit umgehen.
Du trägst die Werte Deiner Sprints ein, beginnend bei Sprint 0. Dann stellst Du zwei Zahlen ein. Beide stehen sichtbar in der Tabelle, nicht versteckt in einer Formel.
- Bis zu welchem Sprint echte Daten vorliegen. Ab dem nächsten Sprint rechnet die Tabelle den Forecast.
- Auf wie vielen der letzten Sprints dieser Forecast beruhen soll.
Die zweite Zahl macht im Alltag den Unterschied. Marek hat sechs Sprints hinter sich und weiß, dass die ersten drei mit ganz anderen Problemen zu kämpfen hatten. Also sagt er der Tabelle, sie soll nur die letzten drei nehmen, und sieht sofort, wie die Vorhersage dann aussieht.
Fairerweise: Die Tabelle löst nur den Teil des Problems, der mit Nachvollziehbarkeit zu tun hat. Die Disziplin, jeden Sprint eine Zahl einzutragen, nimmt sie Dir nicht ab. Und wenn nichts geschätzt ist, hilft sie Dir gar nicht.
[Versions-Burndown Excelvorlage]
Für wen was passt
Wenn ihr euer Ticketsystem selbst administriert und seit Jahren niemand an der Epic-Struktur geschraubt hat, kommst Du mit dem eingebauten Burndown durch. Prüfe nur, ob Deine Stakeholder wirklich verstehen, was sie da sehen.
Wenn die Administration woanders liegt, oder wenn Du Dir das Vertrauen Deiner Stakeholder gerade erst erarbeitest, schreib eine Zahl pro Sprint mit.
Und wenn Du bisher gar keinen Burndown führst, ist die Werkzeugfrage zweitrangig. Fang an, egal womit.
Ich freue mich über Rückmeldungen, auch kritische.
Disclaimer: Die Tabelle oben ist von mir, ich freue mich wenn Du sie nutzt und über diesen Beitrag sprichst. Der Beitrag selbst ist keine Kritik an Atlassian oder Jira, die beschriebenen Probleme entstehen grundsätzlich in allen Ticketsystemen. Für die Pflege des Product Backlog kommt man um diese Systeme nicht herum.
Zur Sprache: Der Fachbegriff lautet „Release Burndown“. Ich sage lieber Versions-Burndown, weil das Wort „Release“ viele Menschen eher verwirrt.
PS: Mir geht ein Gedanke nach, den ich hier nur hinstelle. Ob jemand einen Versions-Burndown dauerhaft mit Team und Stakeholdern pflegen und darüber kommunizieren könnte, wäre eine ziemlich umfassender Eignungstest für die Product Owner Rolle. Denn wer das über zehn Sprints durchhält, führt zwangsläufig beide Unterhaltungen: die mit den Entwickelnden darüber, welche Optionen es gibt, und die mit den Stakeholdern darüber, welche Wünsche diese Version bedient. Der Test führt weg von der abstrakten Frage, ob jemand nur die Autorität hat, hin zur praktischen Frage, ob die Person über die Fähigkeiten und Ressourcen dafür verfügt. Sehr oft hat jemand die Macht, aber nicht die Zeit. Genau dann sollte die Funktion an jemand anderen gehen. Ob Euch das interessiert, weiß ich nicht. Wenn ja, schreibt mir, dann arbeite ich es aus.