Emendare
  • Agile Unternehmensberatung
    • Methode
    • Prinzipien
  • Agile Coaching
  • Agile Workshops
  • Agile Training
    • Agile – Grundlagen Training
    • Agile Führung – Grundlagen
    • Agile Führung – Advanced
    • Scrum Master – CSM
    • Scrum Master – A-CSM
    • Scrum Master – CSP-SM
    • Scrum Master Mikro Trainings
    • Agiles Produkt Management – CSPO | A-CSPO | CSP-PO
  • Agiles Arbeiten
    • Was ist Scrum?
    • Was macht ein Scrum Master?
    • Was macht ein Product Owner?
    • Agile Führung – Was macht eine Agile Führungskraft?
    • Dialogische Unternehmenskultur
  • Unser Team
  • Suche
  • Menü Menü

Magische Burnup Charts und wo sie zu finden sind

Agile Brainfood, Allgemein, Methoden, Produkt

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 Scrum Master 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).

Burnup Chart

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 Scrum Master 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:Burnup Chart

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?

Burnup Chart
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?

Burnup Chart

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

26. Oktober 2021/von Veit Richter
Eintrag teilen
  • Teilen auf Facebook
  • Teilen auf Twitter
  • Teilen auf WhatsApp
  • Teilen auf LinkedIn
  • Per E-Mail teilen
Das könnte Dich auch interessieren
Magic Maze Neues aus dem magischen Labyrinth – 9 neue Erkenntnisse für agile Teams mit Magic Maze
gutes Priorisieren Der Weg zu einer guten Priorisierung ist weit. Manchmal führt er über MoSCoW
Story Splitting Das Story Splitting Cheat Sheet
Langstreckenläuferinnen am Start Schnell, agil oder was denn eigentlich?
Agiles Abnehmen Ist Abnehmen agil?
In japanischen Buchstaben geschrieben "Hoshin Kanri", darum herum Ein Kreis mit den Elementen Plan, Do, Check, Act, verbunden durch Pfeile Hoshin Kanri
Array
Veit Richter
Veit Richter
Agile Coach

Gerne begleite ich Ihre Teams sowohl beim Lernen agiler Praktiken, als auch auf ihrem Weg zur High-Performance. Dabei unterstütze ich sie mit pragmatischen Lösungsstrategien und biete neben meiner Skalierungserfahrung auch Impulse zum Entfesseln positiver Kräfte.

veit.richter@emendare.de

Alle Beiträge von Veit Richter

Letzte Beiträge des Autors

Array
  • Haben „Technische User Stories“ eine Existenzberechtigung?
  • Die Hamburger Methode – technischen Umfang beschränken
  • Was, wenn einmal der Scrum Master krank ist?
  • 1,2 oder 4 Wochen? Wie lang sollte ein Sprint eigentlich sein?
  • Der Weg zu einer guten Priorisierung ist weit. Manchmal führt er über MoSCoW

Kontakt

Emendare GmbH & Co. KG
Karlstraße 87
76137 Karlsruhe

Tel.: +49 (0)721 170 280 08
Email: info@emendare.de

Service

Trainingsbuchung

Impressum

Datenschutzerklärung

Allgemeine Geschäftsbedingungen

Mehr von Emendare

Nachhaltigkeit bei Emendare

Magic Estimation – To complexity and beyond!Fibonacci Folge auf Emendare Schätzkarten Karsten Röth Der Neue im Team
Nach oben scrollen