Bitte wählen Sie eine Seite aus

Burndownchart Antipattern

burndownpattern

Das für die transparente Darstellung der noch offenen Arbeit sehr populäre Burndownchart, verrät uns neben dem offensichtlichen auch so einiges über ggf. vorhandene Dysfunktionalitäten in und außerhalb eines Teams. Dieser Blogbeitrag beleuchtet einige dieser Muster, ihre Ursachen und vor allem Konsequenzen.


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.

Das tägliche Auftragen der noch offenen Arbeit 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. 

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.

Ideal Burndownchart

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 am Sprintende und kaum/kein Fortschritt während des Sprints.

Late Burndown

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.

Burndown Scope Creep

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.

Burndown Slow progress

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.

Burndown Fast

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 Burndown 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.

 

Impressum

Informationspflicht gem. § 5 E-Commerce-Gesetz
Offenlegungspflicht gem. § 25 Medien-Gesetz


Für den Inhalt verantwortlich

agipro-consulting e.U.
Inhaber: DI (FH) Günter S. Bachbauer

Mobil: +43 699 126 19575
E-Mail: office(at)agipro-consulting(dot)at
Internet: http://www.agipro-consulting.at

Firmensitz: 5400 Hallein, Austria
Firmenbuchgericht: Landesgericht Salzburg
FN: 391767 d
UID: ATU67754600

Unternehmensgegenstand des eingetragenen Einzelunternehmens

  • Dienstleistungen in der automatischen Datenverarbeitung und Informationstechnik
  • Unternehmensberatung einschließlich der Unternehmensorganisation gemäß § 94 Z. 74 GewO 1994

Haftungshinweis

Unsere Webseite enthält Verknüpfungen zu Webseiten Dritter (sog. „externe Links“). Da wir auf deren Inhalte keinen Einfluss haben, kann für die fremden Inhalte keine Gewähr übernommen werden. Für die Inhalte und Richtigkeit der Informationen ist stets der jeweilige Informationsanbieter der verlinkten Webseite verantwortlich. Zum Zeitpunkt der Verlinkung waren keine Rechtsverstöße erkennbar. Sobald uns eine Rechtsverletzung bekannt wird, werden wir den jeweiligen Link umgehend entfernen.

Urheberrecht

Die auf dieser Webseite veröffentlichten Inhalte und Werke unterliegen dem österreichischen Urheberrecht. Jede Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechts bedürfen der vorherigen schriftlichen Zustimmung des jeweiligen Urhebers bzw. Autors. Alle Rechte vorbehalten.

Sprachliche Gleichbehandlung

agipro-consulting bemüht sich um die sprachliche Gleichbehandlung von Personenbezeichnungen. Wird in einigen Seiten dennoch nur die männliche Form verwendet, so dient dies einer größeren Verständlichkeit des Textes und soll keinesfalls Frauen gegenüber Männern diskriminieren, sondern für beide Geschlechter gleichermaßen gelten.

×