Wer sich mit Agilität auseinander gesetzt hat kennt sie: Burndown Charts! Doch sehe ich Sie in der tagtäglichen Nutzung so gut wie in keinem Team.
Werden diese doch einmal verwendet, finden sie für 2-3 Sprints intensive Verwendung und gelangen dann in Vergessenheit. Und das ist gar nicht so schlimm.
Neben den Burndowncharts, bin ich persönlich ein großer Fan von „Burnup Charts“. Warum das so ist, ist hier zu lesen.
Burnupcharts
Lasst mich eine Geschichte erzählen. Einst war ich in einem Scrumteam als ScrumMaster angefragt. Das Team durfte auf einer grünen Wiese beginnen und noch im Kickoff Termin machte die Product Ownerin klar: Das hier ist unser fixed Scope und hier seht ihr unsere fixed Time. Das müssen wir also schaffen.
Die Richtung war somit gesetzt und auch der Umfang war dem Team verständlich, in den kommenden Sprints, verließ mich jedoch nicht das Gefühl, dass hier etwas nicht passt.
Kurzerhand schnappte ich mir eine Exceltabelle und erstellte folgendes Bild (Kunde, Datumsangaben und Zahlen sind selbstverständlich abgewandelt).
Eine „Magic Estimation“ machte transparent, dass der von vornherein angedachte Umfang ca. 500 Storypoints beträgt. Die genormte Geschwindigkeit des Teams nach 3 Sprints zeigte eine ungefähre Vorhersage, wie es weiter gehen könnte.
Ernüchternd konnte ich meinem Bauchgefühl visuell Gewicht verleihen: „Liebste Katharina, das wird leider vorn und hinten nicht klappen. Zu dem aktuell angedachten Enddatum werden wir wohl realistisch betrachtet gerade einmal rund 300 Storypoints fertig haben, obwohl du dir 500 gewünscht hast. Wir müssen etwas tun!“
Selbstverständlich erntete ich keine freudigen Emotionen, doch die Transparenz wurde akzeptiert. Gemeinsam mit dem Team besprachen wir, was wir tun könnten.
- Wir könnten die Zeit verlängern! Hm…
- Wir könnten noch mehr Entwickler auf das Produkt werfen! Hmmmm….
- Wir könnten uns Gedanken machen, welche Items den höchsten Wert bringen und die Priorisierung hinterfragen! Ahh!! 🙂
Die Erkenntnisse
Mithilfe der gewonnen Transparenz und einem durch den ScrumMaster gestärkten Rücken trat unsere PO in die Verhandlungen mit den Stakeholdern und schnell ergab sich dank einer MoSCoW Priorisierung (Siehe im Artikel zu MoSCoW) folgendes Bild:
Eine kurze Erklärung zu dem, was im Bild zu sehen ist:
- Die dunkelblauen Balken zeigen die jeweilige Velocity des Sprints
- Die schwarze Linie
- bis Sprint 9 – zeigt die kumuliert erreichten Storypoints des Teams
- ab Sprint 9 – zeigt einen realistischen Forecast, basierend auf dem gleitenden Durchschnitt der letzten 3 Sprints
- Die rote Linie zeigt einen pessimistischen Forecast, basierend auf den 3 „schlechtesten“ Velocities der letzten 5 Sprints
- Die grüne Linie zeigt einen optimistischen Forecast, basierend auf den 3 „besten“ Velocities der letzten 5 Sprints
- Die grüne Fläche zeigt, was vom Product Backlog bereits abgearbeitet wurde
- Die dunkelblaue Fläche zeigt die „Must“-Kriterien
- Die hellblaue Fläche zeigt die „Should“-Kriterien
- Die graue Fläche zeigt die „Could“-Kriterien
Durch die frühe Transparenz und die MoSCoW Methodik konnte die Product Ownerin in alle Richtungen Entspannung erzeugen. Das Team fühlte sich nicht mehr von unbezwingbaren Bergen an Arbeit erschlagen, die Product Ownerin wusste, dass sie zum gewünschten Zeitpunkt etwas liefern konnte und die Stakeholder hatten das Gefühl in guten Händen zu sein und kannten die Maßnahmen.
Die Zeit für eine Produktentwicklung zu erhöhen ist immer möglich, einen kleineren Scope zu fokussieren und wichtige Arbeit nach oben zu priorisieren nicht. Hier würde ich also immer empfehlen erst den Priorisierungsansatz und erst danach den Zeitansatz zu wählen.
Wie es zu lesen ist
Mithilfe des Charts sind 2 Fragen schnell zu beantworten:
Fixed Time Frage:
Wie viel wird bis zum Ende von Sprint 16 erledigt sein?
Hier kann der Product Owner die Prognosen zur Hand nehmen und sagen:
- Pessimistisch gesehen, werden wir 250 Storypoints fertig haben
- Optimistisch werden wir bei 380 Storypoints rauskommen
- Realistisch betrachtet landen wir bei 300 Storypoints
„Lieber Stakeholder, wenn wir vom pessimistischen Ergebnis ausgehen, welche 250 Storypoints hättest du bis dahin gern?“
Fixed Scope Frage:
Bis wann werden wir alle „Must“ Criteria fertig haben?
Dank der Vorhersage kann der Product Owner folgende Antwort geben:
- Pessimistisch werden wir für dieses Featureset bis zum Ende von Sprint 21 fertig
- Optimistisch könnten wir schon in Sprint 13 diese Inhalte haben
- Realistisch dürfen wir mit Sprint 16 rechnen
„Lieber Stakeholder, lass uns doch einmal auf das früheste Datum fokussieren, welche Items wären dir hierfür am wichtigsten, um danach entscheiden zu können, ob wir noch etwas mehr Zeit investieren dürfen?“
Wie startet man mit Burnup Charts?
Sehr gern kann ich euch das Template zur Verfügung stellen, welches auch die beiden Bilder in diesem Artikel erzeugt hat. Andere Werkzeuge wie Jira haben diese Forecasts sogar schon selbst an Board. Von beiden Lösungen würde ich jedoch abraten!
Ein eigenes Burnupchart mithilfe eines Flipcharts oder Excel auf die Beine zu stellen, hilft das Verständnis für Projektfortschritt und Prognosen zu schärfen und sich tiefer mit der Thematik auseinander zu setzen.
Du möchtest noch mehr zu Burnup Charts erfahren? Du hättest dennoch gern das Template oder wünscht dir Unterstützung dabei ein Projekt, welches schon etwas spät dran ist zu einem Erfolg zu führen? Dann schreib mir doch gern eine Mail an: veit.richter@emendare.de