😱Die 4 schlimmsten Burndownchart Antipattern

Das Burndownchart oder Burndown Diagramm eines agilen Teams zeit uns neben der noch offenen Arbeit auch so einiges über vorhandene Dysfunktionalitäten und Schwierigkeiten des Prozesses in und außerhalb eines Teams. Dieser Blogbeitrag beleuchtet einige dieser Antipattern, ihre Ursachen, Konsequenzen und mögliche Lösungsansätze.

Agile Teams messen Fortschritt anhand funktionierender und potenziell einsetzbarer Ergebnisse. Damit erledigen sich endlose und fragwürdige Diskussionen, ob ein Feature zu 80 oder 90% fertig ist. Entweder das Ergebnis erfüllt die definierten Anforderungen bzw. Akzeptanzkriterien oder eben nicht. Diese binäre Sicht erleichtert auch die Abnahme von Ergebnissen.

Das tägliche Auftragen der noch offenen Arbeit im Burndownchart in z.B. Storypoints (nur erledigte „Done“ Stories werden subtrahiert) ergibt ein für jedes Team bzw. Sprint eindeutiges Muster. Manche negative Muster / Antipattern wiederholen sich und haben oft ähnliche Ursachen. 

Burndownchart Idealfall

Im Idealfall liegt die aufgetragene Burndown-Linie genau auf der virtuellen, grauen Ideallinie und entwickelt sich annähernd linear nach unten. Befindet sich das Burndown eines Teams oberhalb der Ideallinie ist es zu langsam, liegt es darunter ist es ggü. der gedachten Ideallinie zu schnell unterwegs.

Grundlage für den Idealfall sind ein tatsächlich interdisziplinäres Team mit Ende-Ende Verantwortung, die kontinuierliche Fertigstellung von Backlog Items während des gesamten Sprints, die Verfügbarkeit aller Teammitglieder inkl. PO und ein realistisches Sprint Planning ohne Einwirkung von außen während des Sprints.

Antipattern 1: Späte Fertigstellung von Backlog Items

Die Mehrheit der Backlog Items wird erst gegen Ende des Sprints abgeschlossen bzw. durch den PO abgenommen. Charakteristisch ist der extreme Sprung im Burndownchart am Sprintende und kaum/kein Fortschritt während des Sprints. Sehr gut sichtbar im Burndownchart.

Ursachen

Abwesender oder nicht verfügbarer Product Owner: Der Product Owner ist kaum für das Team verfügbar und nimmt Stories nur „nebenbei“ ab. Dadurch entsteht eine künstliche Warteschleife.

Silos innerhalb des Teams: Das Team arbeitet nicht wirklich interdisziplinär zusammen. Ergebnisse werden erst sehr spät an die Tester übergeben, die dann alles am Ende abschließen „müssen“. De facto Mini-Wasserfall.

Paralleler Beginn: Ein Großteil der Stories wird zeitgleich begonnen und parallel entwickelt. Gefahr besteht, dass zwar alles gestartet aber nichts abgeschlossen und somit kein Wert geliefert werden kann.

Konsequenzen

Verspätete Abnahme: Die Abnahme von Backlog Items immer erst am Sprintende möglich. Keine kontinuierliche Lieferung von Wert.

Überforderung Product Owner: „Alles kommt gleichzeitig am Ende“.

Metrik: Fortschritt innerhalb des Sprints kaum messbar.

Sprintziele: Schwer erreichbar und Teile des Sprint Backlogs wandern in den nächsten Sprint.

Frustration: Teile oder das ganze Team werden frustriert.

Stillstand: Bei mehrmaligem Auftreten besteht keine Weiterentwicklung des agilen Teams.

Antipattern 2: Erweiterung Sprint Backlog während des Sprints

Der Inhalt des Sprint Backlogs wird während eines laufenden Sprints erhöht (oder verringert). Es kommen neue oder stark geänderte Backlog Items dazu. Allgemein wird dieser Umstand oft als sog. „Scope-Creep“ bezeichnet. Die Kurve geht im Burndownchart geht nach oben anstatt nach unten.

Ursachen

Fehlerhafte Planung: Das Sprint Planning umfasst nicht den tatsächlichen Sprint Backlog, sondern nur Teile.

Unzureichendes Refinement: Das Team akzeptiert schlecht verstandene oder nicht diskutierte Anforderungen.

Produktionsbugs: Bugs werden ergänzt und alle bestehenden Teile des ursprünglichen Sprint Backlogs bleiben erhalten. Dadurch erhöht sich der Gesamtinhalt ggü. der Planung.

Dysfunktionales Team: Das Team inkl. SM akzeptieren Ergänzungen durch den (autoritären) PO und/oder externe Parteien ohne vorheriges Planning – der Sprint ist nicht geschützt.

Konsequenzen

Unplanbar: Das Sprintziel ist plötzlich beweglich, was es in Konsequenz unmöglich macht die anvisierten Ziele zu erreichen.

Kein Commitment: Laufende Änderungen während des Sprints untergraben das Team-Commitment und verhindern die Erreichung des Sprint Ziels.

Fehlende Glaubwürdigkeit: Das Team verliert Glauben an die vereinbarten Regeln und beginnt sie zu umgehen oder noch schlimmer ignoriert sie völlig.

Konflikte: Bei mehrfachen Auftreten werden zwangsläufig Konflikte auftreten.

Antipattern 3: Geringer oder langsamer Fortschritt

Die Velocity der Umsetzung ist deutlich langsamer als erwartet. Der Fortschritt entspricht nicht den Erwartungen. Das Sprintziel kann nicht erreicht werden.

Ursachen

Ambitioniertes Team: Das Team überschätzt sich und plant zu viel ein. Erst innerhalb des Sprints realisiert das Team diesen Umstand.

Technische Herausforderungen: Die ursprüngliche Implementierung ist nicht möglich oder komplexer, als erwartet. Anstatt diesen Umstand mit dem PO zu klären versucht das Team weiterhin das Sprintziel zu erreichen und scheitert letztlich.

Verringerte Kapazität: Die Kapazität im Sprint ist durch Ausfall / Wegfall von Teammitgliedern reduziert. Krankheitsbedingte Ausfälle sind nicht planbar.

Änderung der Priorität: Änderung der Priorisierung des Sprint Backlogs durch Arbeit an Produktionsbugs verringert Kapazität, um Sprintziel zu erreichen.

Externe Abhängigkeiten: Ungeplante, externe Abhängigkeiten und/oder Blockaden behindern das Team im Vorankommen.

Konsequenzen

Vertrauensverlust: Die Organisation bzw. Stakeholder verliert bei mehrmaligem Auftreten das Vertrauen in das Team.

Verringerte Velocity: Die Geschwindigkeit des Teams ist verringert und kann Auswirkungen auf künftige Plannings haben.

Geringeres Selbstvertrauen: Das Team verliert das Vertrauen in sich selbst – ein Teufelskreis.

Antipattern 4: Zu rascher Fortschritt

Das Team kann die geplanten Anforderungen deutlich schneller als geplant umsetzen und ist vor Sprintende fertig.

Ursachen

Vorsichtiges Team: Das Team plant bewusst zu wenig ein. Das kann absichtlich (Angst vor Nicht-Fertigstellung) oder unabsichtlich (neues Team) geschehen.

Überschätzung Komplexität: Die geplanten Items wurden überschätzt. Auch hier ist Unerfahrenheit eine mögliche Ursache. Alternativ gibt es möglicherweise einfache Lösungswege, die zu Beginn unbekannt waren.

Erhöhte Kapazität: Selten aber doch ist auch eine Erhöhung der Kapazität im laufenden Sprint (z.B. Rückkehr nach Krankheit) möglich. Dieser Fall ist aber eher selten.

Konsequenzen

Vertrauensverlust: Die Organisation bzw. Stakeholder verliert bei mehrmaligem Auftreten das Vertrauen in das Team.

Planning notwendig: Ein neues Planning ist notwendig.

Vorzeitiges Sprint-Ende: Nicht zwingend negativ – der PO kann den Sprint aufgrund vorzeitiger Fertigstellung früher als geplant beenden. Das ist nicht empfehlenswert.

Fazit

Das Burndownchart lässt mehr Rückschlüsse auf die Zusammenarbeit und mögliche Problem zu, als es auf den ersten Blick scheint. Ein erfahrener und empathischer ScrumMaster wird diese Muster erkennen und versuchen gemeinsam mit dem Team Verbesserungen zu erarbeiten.

Wichtig ist zu verstehen, dass das Burndownchart nur ein Tool ist und dem Team dienen muss. Es ist keinesfalls ein Kontroll- oder Überwachungsinstrument. Intelligent eingesetzt und verstanden kann das Burndown eine echte Unterstützung für Teams bei der fortlaufenden Verbesserung und der Schaffung von Transparenz sein.