Scrum-Leitfaden | 31. Wie erstellt und interpretiert man ein Burndown-Diagramm?

Veröffentlicht: 2022-06-21

Ein Burndown-Diagramm ist relativ einfach zu erstellen. Es stehen viele Tools zur Verfügung, um es aus der von Mitgliedern des Entwicklungsteams protokollierten Arbeit zu generieren. Trotz seiner Einfachheit kann seine Interpretation wertvolle Informationen für das gesamte Scrum-Team liefern. Lesen Sie diesen Artikel, um herauszufinden, wie Sie ein Burndown-Diagramm erstellen und interpretieren.

Wie erstellt und interpretiert man ein Burndown-Diagramm? - Inhaltsverzeichnis:

  1. Wie erstelle ich ein Burndown-Diagramm?
  2. Wer ist für das Burndown-Chart verantwortlich?
  3. Wie interpretiert man ein Burndown-Diagramm?
  4. Echtes und ideales Burndown-Diagramm
  5. Auswahl der Maßeinheit
  6. Zusammenfassung

Wie erstelle ich ein Burndown-Diagramm?

Das Entwicklungsteam sollte seine tägliche Arbeit überwachen. Dies ist die Grundlage, um seine Wirksamkeit nicht nur zu bewerten, sondern auch zu verbessern. Und eines der einfachsten und bewährtesten Werkzeuge für diesen Zweck ist das Brenndiagramm.

Sie können es manuell erstellen, indem Sie ein Koordinatensystem auf ein Blatt Papier zeichnen. Auf der Y-Achse müssen Sie den Arbeitsaufwand, ausgedrückt in einer gewählten Einheit, zum Beispiel Story Points, darstellen. Zeichnen Sie auf der X-Achse eine Skala, die die aufeinanderfolgenden Tage des Sprints anzeigt. Zeichnen Sie eine Linie des idealen Sprints und markieren Sie dann die Anzahl der realistisch erledigten Aufgaben für jeden Tag. Obwohl diese Lösung charmant ist und das Team fesselt, ist sie nicht sehr praktisch. Es ist auch nicht unbedingt für Remote-Teams geeignet.

Daher sind digitale Mittel zur Erstellung eines Burndown-Diagramms viel verbreiteter. Viele Tools zum Protokollieren der Arbeit an Aufgaben, die auf Teammitglieder verteilt sind, verfügen über eine Option zum automatischen Erstellen eines Burndown-Diagramms. Dann muss ein Entwickler nur noch den Beginn und das Ende der Arbeit an einer bestimmten Produktfunktion markieren, und sein Beitrag wird im Burn-Chart widergespiegelt.

Mit den richtigen Werkzeugen ist es auch möglich, das Diagramm frei zu skalieren. Dies gibt einen Einblick in die Verbrennung nicht nur auf der Ebene eines bestimmten Sprints, sondern auch im Maßstab eines Quartals oder des gesamten Projekts.

Ein wichtiger Faktor, der bei der Auswahl eines Tools zum Erstellen eines Burndown-Diagramms zu berücksichtigen ist, ist seine Zugänglichkeit für alle Mitglieder des Scrum-Teams. Die Sichtbarkeit des Burndown-Diagramms für das gesamte Entwicklungsteam ist ein wichtiger Motivationsfaktor. Ebenso wichtig ist ein täglicher Blick auf die Linie der noch zu erledigenden Arbeiten. Wenn er über Burn-in während des Daily Scrum spricht , bringt er Entwickler dazu, über ihre Arbeitsweise und den aktuellen Stand des Produkts nachzudenken.

Wer ist für das Burndown-Chart verantwortlich?

Etwas umstritten ist die Eigentumsfrage des Burn Charts. Einerseits sollte es dem Scrum Master gehören, denn es ist ein Werkzeug, um sicherzustellen, dass das Team effizient und nach Plan arbeitet. Andererseits sollte es in den Händen des Product Owners bleiben, da es den Fortschritt in Richtung eines Produktziels widerspiegelt, das dem Kunden mitgeteilt wird. Darüber hinaus ist das Entwicklungsteam ein Dritter, der sein Eigentum beansprucht, da das Diagramm als internes Werkzeug fungiert.

Das Burndown-Diagramm ist eine wesentliche Metrik zur Bewertung der Effektivität des Entwicklungsteams und wird von allen Scrum-Teammitgliedern übernommen. Deshalb sind Transparenz und Zugänglichkeit entscheidend. Sein eigentlicher Zweck ist es jedoch, dem Team zu dienen. Es soll seine Selbstorganisation stärken, die Motivation verbessern und ein reales Bild vom Stand der Arbeit an den ihm übertragenen Aufgaben vermitteln. Daher kann theoretisch jedes Mitglied des Entwicklungsteams das Brenndiagramm aktualisieren.

In der Praxis fällt die Aktualisierung des Burndown-Charts jedoch meist dem Scrum Master zu. Dies passiert vor allem zu Beginn seiner Arbeit mit einem neuen Entwicklungsteam, wenn die Team Velocity noch schwankend und schwer einzuschätzen ist. Dennoch wird empfohlen, diese Aufgabe an einen der Entwickler zu delegieren. Schließlich soll das Diagramm eine ehrliche und interne Messung des Fortschritts der Arbeit sein, wie sie von den Entwicklern selbst beurteilt wird.

chart

Wie interpretiert man ein Burndown-Diagramm?

Das Aussehen des Burndown-Diagramms haben wir in einem früheren Artikel ausführlich beschrieben. Hier erinnern wir Sie nur daran, dass die X-Achse die verbleibende Zeit bis zur Fertigstellung der Arbeit anzeigt. Andererseits zeigt die Y-Achse die Menge der noch zu erledigenden Arbeit.

Echtes und ideales Burndown-Diagramm

Entscheidend für die Interpretation eines Burndown-Charts ist nicht nur das regelmäßige Plotten der realen „Verbrennung“, also der Aufgabenerledigung durch das Entwicklungsteam. Ebenso wichtig für das Bild ist der Vergleich mit dem idealen Brennlinienabfall (Richtwert).

Durch den Vergleich der idealen Verbrennungslinie mit der im Burndown-Diagramm markierten realen Arbeitserleichterung können zwei sehr wichtige Parameter bewertet werden. Erstens, um zu sehen, ob die Arbeit im aktuellen Tempo fortgesetzt wird, wird das Entwicklungsteam das Sprint-Ziel oder das Produktziel rechtzeitig erreichen. Zweitens, um eine Vorstellung davon zu bekommen, wann die Arbeit abgeschlossen sein wird, während das aktuelle Tempo beibehalten wird. Mit anderen Worten, das Burn-Diagramm zeigt das tatsächliche Tempo der Aufgaben, und die Ideallinie zeigt, in welchem ​​​​Tempo das Team arbeiten sollte, um die Aufgaben zu erledigen.

Über den Burn-Graph lässt sich auch langfristig ein Wert namens Development Team Velocity ermitteln. Wir werden ihm einen eigenen Artikel widmen. Hier erwähnen wir nur, dass es sich um einen Wert handelt, der durch die Menge an Arbeit bestimmt wird, die während eines Sprints geleistet wird.

Dank der Tatsache, dass das Burn-Chart den Vergleich einer idealen Burn-Linie mit einer realen Abnahme der Anzahl von Aufgaben darstellt, ermöglicht es Ihnen, das Arbeitstempo abzuschätzen. Und antizipieren Sie so das Risiko von Projektverzögerungen.

Auswahl der Maßeinheit

Die Teamgeschwindigkeit wird normalerweise in Einheiten gemessen, die als Story Points bezeichnet werden. Sie definiert die Anzahl der realisierten User Stories. Diese können einen sehr unterschiedlichen Arbeitsaufwand erfordern.

Aus diesem Grund verwenden viele Scrum-Teams eine zeitbasierte Maßnahme. Je nach Maßstab sind dies Tage oder Arbeitsstunden. Jeder Entwickler schätzt und protokolliert dann die für seine Aufgaben aufgewendete Zeit.

Eine weitere Möglichkeit besteht darin , Aufgaben als Einheit zu übernehmen. Dies sind etwas größere Einheiten, denen wiederum ein Wert in Story Points oder in Tagen oder Arbeitsstunden zugewiesen wird. Es ist eine Einheit, die es dem Kunden ermöglicht, den Fortschritt der Arbeit am Produkt übersichtlicher darzustellen.

Unabhängig von der Maßeinheit ist es wichtig, sich an das Prinzip der Berechnung der Geschwindigkeit des Entwicklungsteams zu erinnern. An einem bestimmten Tag oder Sprint zählen nur Aufgaben, die tatsächlich erledigt wurden. Das bedeutet, dass begonnene Aufgaben auf den nächsten Tag oder Sprint angerechnet werden, auch wenn nur abschließende Tests fehlen.

Zusammenfassung

How to create and interpret a burndown chart?

Mit den verfügbaren Teamüberwachungstools wird das Erstellen eines Burndown-Diagramms zu einer einfachen Aufgabe. Das Wichtigste ist, seine Kohärenz, Klarheit und Zugänglichkeit für alle Mitglieder des Scrum-Teams sicherzustellen.

Wenn Ihnen unsere Inhalte gefallen, werden Sie Teil unserer fleißigen Bienen-Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 31. How to create and interpret a burndown chart? caroline becker avatar 1background

Autorin: Caroline Becker

Als Projektmanagerin ist Caroline Expertin darin, neue Methoden zu finden, um die besten Arbeitsabläufe zu gestalten und Prozesse zu optimieren. Ihre organisatorischen Fähigkeiten und ihre Fähigkeit, unter Zeitdruck zu arbeiten, machen sie zur besten Person, um komplizierte Projekte in die Realität umzusetzen.

Alle Beiträge anzeigen

Scrum-Leitfaden:

  1. Glossar der Grundbegriffe, Rollen und Begriffe
  2. Was ist Scrum?
  3. Scrum-Werte
  4. Wie implementieren Sie Scrum in Ihrem Unternehmen?
  5. Scrum Team – was ist das und wie funktioniert es?
  6. Wer ist ein Product Owner?
  7. Die häufigsten Fehler des Product Owners
  8. Wer ist der Scrum-Master?
  9. Eigenschaften eines guten Scrum Masters
  10. Die häufigsten Fehler des Scrum Masters
  11. Welche Statistiken und Metriken sollte der Scrum Master verfolgen?
  12. Zusammenarbeit zwischen Product Owner und Scrum Master
  13. Entwicklungsteam in Scrum
  14. Die häufigsten Fehler von Entwicklern
  15. Scrum-Artefakte
  16. Scrum skalieren
  17. Sprint-Rückstand
  18. Was ist das Product Backlog?
  19. Was sind User Stories?
  20. Erstellen Sie die beste User Story mit INVEST
  21. Die häufigsten Fehler in User Storys
  22. Akzeptanzkriterien für User Storys
  23. Schätzung und Story Points in Scrum
  24. Planungspoker
  25. Team-Schätzspiel
  26. Inkrement definieren
  27. Scrum-Ereignisse
  28. Was ist Sprint in Scrum?
  29. Verpflichtungen des Scrum-Teams – Produktziel, Sprintziel und Abschlussdefinition
  30. Was ist ein Burndown-Diagramm?
  31. Wie erstellt und interpretiert man ein Burndown-Diagramm?
  32. Vor- und Nachteile des Burndown-Charts
  33. Kanban-Boards in Scrum und Scrumban
  34. Velocity in Scrum - Schnelligkeit des Entwicklungsteams
  35. Tägliches Scrum
  36. Sprint-Planung
  37. Sprint-Review
  38. Was ist eine Sprint-Retrospektive?
  39. Häufige Fehler während einer Sprint-Retrospektive
  40. Pflege des Produkt-Backlogs