3 agile Burndown-Berichte und deren Verwendung

Agile Praktiken für Uneingeweihte und Unterinformierte können manchmal als Ad-hoc-Methoden für Softwareentwicklung und Projektmanagement erscheinen. Die Wahrheit ist ganz anders.

Eines der 12 Prinzipien agiler Software lautet: „Die besten Architekturen, Anforderungen und das beste Design ergeben sich aus selbstorganisierenden Teams.“ Die meisten Organisationen, die agile Praktiken anwenden, einschließlich Scrum und Kanban, erzwingen jedoch einige wichtige Prozessanforderungen und -rituale. Beispielsweise implementieren viele Unternehmen agile Planungspraktiken, einschließlich Story-Point-Schätzung, Architekturstandards und Release-Management-Disziplinen, um die geschäftlichen Auswirkungen, die Qualität und die Zuverlässigkeit von Anwendungsversionen zu verbessern.

Die meisten Teams verwenden ein agiles Tool wie Jira Software oder Azure DevOps, um die Rückstände, Sprints und die Zusammenarbeit zwischen agilen Teams zu verwalten. Der Hauptzweck dieser Tools besteht darin, die Anforderungen, den Sprintstatus, den Workflow und die Zusammenarbeit zwischen agilen Teammitgliedern und mehreren agilen Teams zentral zu verwalten. Je strenger Organisationen diese Tools einsetzen, desto mehr können diese Tools Führungskräften und Teams dabei helfen, Probleme zu identifizieren, den Stakeholdern über den Status Bericht zu erstatten und ihre Ausführung zu verbessern.

Einer der häufigsten sofort einsatzbereiten Berichte ist der Burndown-Bericht. Da agile Praktiken es Produktbesitzern ermöglichen, den Rückstand basierend auf Kundenfeedback neu zu priorisieren, können herkömmliche Berichte wie Gantt-Diagramme die Fluidität der agilen Ausführung nicht erfassen. Grundlegend für das Burndown-Diagramm ist, dass es abgeschlossene Arbeiten, neue Arbeiten, die dem Bereich hinzugefügt wurden, und andere Änderungen des Bereichs berücksichtigt. Das Burndown-Diagramm kann ein schnelles Bild davon liefern, wie Teams auf ihre Ziele zusteuern.

Lesen eines grundlegenden Sprint-Burndown-Diagramms

Burndown-Diagramme haben normalerweise Zeit auf der x-Achse und Schätzungen auf der y-Achse. Viele Teams schätzen in Story-Punkten, aber viele agile Tools können Burndowns anhand der Anzahl der Storys oder Schätzungen in Stunden darstellen. Für diesen Artikel gehe ich davon aus, dass Story Points verwendet werden.

Der Sprint-Burndown-Bericht zeigt die Anzahl der Story-Punkte, die für das Zeitintervall gelten. Während das Team die Storys fertigstellt, zeigt das Diagramm, wie die Liste der Storys und anderer Arbeitstypen (Probleme in Jira, Workitemtypen in Azure DevOps) "abgebrannt" wird, bis die Arbeit abgeschlossen ist oder der Sprint endet. Wenn die Teams die für den Sprint festgelegte Arbeit abgeschlossen haben, schneidet die gezeichnete Linie die x-Achse und zeigt damit an, dass alles erledigt ist.

Der Sprint-Burndown ist am einfachsten zu konzipieren. Am ersten Tag des Sprints legt das Team einige Geschichten und die Gesamtzahl der Punkte fest. Wenn Sie das Burndown-Diagramm an diesem Tag überprüfen, sollte auf der y-Achse ein einzelner Punkt angezeigt werden, der die Anzahl der Punkte darstellt, für die sich das Team am Tag Null des Sprints entschieden hat.

Wenn die Storys als erledigt markiert sind, zeigt der Sprint-Burndown die verbleibende Anzahl an Punkten an, die abgeschlossen werden müssen.

Wie wird ein Sprint Burndown in der Praxis eingesetzt? Ein gesunder Burndown zeigt eine lineare und idealerweise exponentielle Kurve bis auf Null. Wenn die Kurve zu Beginn eines Sprints eine flache Steigung aufweist, kann dies auf Blöcke oder viel laufende Arbeit hinweisen und darauf hinweisen, dass der Sprint gefährdet sein kann. Ein flacher oder langsam abfallender Burndown kann sehr problematisch sein, wenn viele Tests an Code-vollständigen Storys durchgeführt werden und die Testarbeiten erst in den letzten Tagen des Sprints beginnen können.  

Ein schnell absteigender Sprint-Burndown ist im Allgemeinen eine gute Sache, kann jedoch darauf hinweisen, dass das Team zu wenig Engagement hat oder sich nur dafür entschieden hat, kleinere Storys im Sprint zu übernehmen.

Epische Burndowns verfolgen den Fortschritt gegenüber geschäftlichen und technischen Treibern

Sprint-Burndowns sind sehr nützlich, um die kurzfristige Ausführung zu verfolgen und Teams dabei zu helfen, Sprint-Verpflichtungen erfolgreich zu erfüllen. Um den Fortschritt in Bezug auf längerfristige Ziele besser verfolgen zu können, bieten epische und Release-Burndowns die erforderliche Sichtbarkeit.

Epische Burndowns funktionieren am besten, wenn Teams mehrere langfristige Anstrengungen definieren, z. B. die Implementierung wichtiger Endbenutzerfunktionen, technischer Schuldenstrategien, Leistungsverbesserungen oder Prozessentwicklungen. Um epische Burndowns nutzen zu können, sollte der Rückstand Folgendes haben:

  • Zwischen fünf und 15 Epen, die mindestens mehrere Monate dauern und sechs oder mehr Sprints benötigen.
  • Features, Geschichten und Story Stubs, die unter dem Epos auftauchen und einen hochrangigen Plan für die Ausführung des Epos darstellen.
  • Hochrangige Schätzungen, idealerweise in Story-Punkten für jede Story oder jeden Story-Stub, der unter den Epen auftaucht.

Sobald diese vorhanden sind, zeichnet der epische Burndown die Änderungen an diesem Plan auf. Die x-Achse repräsentiert Sprints und die y-Achse repräsentiert die Gesamtschätzung der Geschichten und Story Stubs, die dem Epos zugeordnet sind. Im epischen Burndown-Diagramm von Jira Software sehen Sie ein Balkendiagramm mit einer Farbe, die die im Sprint abgeschlossenen Storys darstellt, und einer zweiten, die die hinzugefügten Story-Punkte zeigt. Story-Punkte erhöhen sich, wenn dem Epos neue Storys oder Story-Stubs hinzugefügt werden oder wenn sich Schätzungen ändern.

Es gibt verschiedene Möglichkeiten, das epische Burndown-Diagramm zu verwenden:

  • Es zeigt die Geschwindigkeit, mit der Features und Storys gegen den Plan fertiggestellt werden. Wenn die Pläne genau und die Teamgeschwindigkeit konsistent sind, kann dies einen Indikator dafür liefern, wann die Arbeit des Epos abgeschlossen ist.
  • Die meisten agilen Pläne sind nicht vollständig, und die Teams fügen Storys hinzu, ändern sie und entfernen sie basierend auf dem Feedback der Endbenutzer, der Entdeckung technischer Komplexität und der Behebung technischer Schulden, die während der Reise entstanden sind. Der epische Burndown zeigt dann an, wie weit das Epos vom Plan entfernt ist, basierend darauf, wie stark der Rückstand wächst, anstatt Sprint für Sprint abgeschlossen zu werden.
  • Epische Burndowns helfen auch dabei, die Bemühungen über mehrere Sprints hinweg zu vergleichen und zu messen, wie viel Planungs- und Lieferarbeit in einem Epos im Vergleich zu anderen geleistet wird.

Release-Burndowns informieren die Teams darüber, ob Releases Datum und Umfang erreichen

Fortgeschrittene Teams, die ihre Lieferpipelines durch kontinuierliche Integration, kontinuierliche Tests und kontinuierliche Lieferung vollständig automatisieren, benötigen möglicherweise keine Release-Burndowns. Teams, die häufig bereitstellen, sollten nachverfolgen, welche Funktionen und Storys mit der Veröffentlichung verbunden sind. Der Burndown der Veröffentlichung ist jedoch nicht sehr nützlich, da er häufig den Fortschritt im Sprint verfolgt.

Für andere Teams, die Release-Management-Praktiken befolgen und auf Multisprint-Releases standardisieren, ist der Release-Burndown möglicherweise das wichtigste Tool des Produktbesitzers und des Teams.

Der Release-Burndown ähnelt dem epischen Burndown, außer dass anstelle der Verfolgung von Funktionen, Storys und Story-Stubs, die einem Epos zugewiesen sind, der Release-Burndown zeigt, was einem Release zugewiesen ist. Die Achse und die Balken sind dann identisch mit epischen Burndowns.

Teams, die Release-Burndowns verwenden, können somit Umfang und Zeitplan für eine Veröffentlichung verfolgen. Teams, die auf der Strecke sind, sehen eine Burndown-Steigung bis zur x-Achse mit einer Steigung, die der Geschwindigkeit des Teams entspricht. Veröffentlichungen, die möglicherweise vom Kurs abweichen, haben entweder eine geringere Steigung oder zeigen mehr Story-Punkte, die hinzugefügt werden (wenn der Veröffentlichung mehr Umfang hinzugefügt wird), als fertiggestellt werden.

Jira Software hilft Ihnen bei diesen Projektionen. Angenommen, das Team hat mindestens drei Sprints an dem Projekt gearbeitet, berechnet Jira Software eine durchschnittliche Teamgeschwindigkeit und sagt den Endsprint für eine Veröffentlichung basierend auf dieser Geschwindigkeit voraus.

Die Sprint-, Epic- und Release-Burndowns bieten den Teams einige benutzerfreundliche Tools, mit denen sie sich an den Zielen ausrichten können. Wenn Teams ein gemeinsames Verständnis des Umfangs haben, Prioritäten vereinbaren, mehrere Sprints im Voraus planen und Storys in ihrem Backlog entsprechend kennzeichnen, erzählen Burndowns, ob Planung und Ausführung mit den Zielen in Einklang stehen. Wenn dies nicht der Fall ist, handelt es sich um ein datengesteuertes Tool, mit dem diskutiert werden kann, welche Anpassungen möglicherweise erforderlich sind.