Ein Burndown-Diagramm ist relativ einfach zu erstellen. Es gibt viele Werkzeuge, die es ermöglichen, es aus den von den Mitgliedern des Entwicklungsteams erfassten Arbeiten zu generieren. Trotz seiner Einfachheit kann seine Interpretation wertvolle Informationen für das gesamte Scrum-Team liefern. Lesen Sie diesen Artikel, um herauszufinden, wie man ein Burndown-Diagramm erstellt und interpretiert.
Wie erstellt und interpretiert man ein Burndown-Diagramm? – Inhaltsverzeichnis:
- Wie erstellt man ein Burndown-Diagramm?
- Wer ist verantwortlich für das Burndown-Diagramm?
- Wie interpretiert man ein Burndown-Diagramm?
- Reales und ideales Burndown-Diagramm
- Auswahl der Maßeinheit
- Zusammenfassung
Wie erstellt man ein Burndown-Diagramm?
Das Entwicklungsteam sollte seine tägliche Arbeit überwachen. Dies ist die Grundlage, um nicht nur die Effektivität zu bewerten, sondern auch um sie zu verbessern. Und eines der einfachsten und bewährtesten Werkzeuge zu diesem Zweck ist das Burndown-Diagramm.
Sie können es manuell erstellen, indem Sie ein Koordinatensystem auf ein Blatt Papier zeichnen. Auf der Y-Achse müssen Sie die Menge an Arbeit, ausgedrückt in einer gewählten Einheit, zum Beispiel Story Points, eintragen. Auf der X-Achse zeichnen Sie eine Skala, die die aufeinanderfolgenden Tage des Sprints anzeigt. Zeichnen Sie eine Linie des idealen Sprints und markieren Sie dann die Anzahl der realistisch abgeschlossenen Aufgaben für jeden Tag. Obwohl diese Lösung charmant ist und das Team einbezieht, ist sie nicht sehr praktisch. Sie ist auch nicht unbedingt für Remote-Teams geeignet.
Daher sind digitale Mittel zur Erstellung eines Burndown-Diagramms viel verbreiteter. Viele Werkzeuge zur Protokollierung der Arbeit an Aufgaben, die unter den Teammitgliedern verteilt sind, bieten die Möglichkeit, ein Burndown-Diagramm automatisch zu erstellen. Dann muss ein Entwickler nur den Beginn und das Ende der Arbeit an einem bestimmten Produktmerkmal markieren, und sein Beitrag wird im Burndown-Diagramm reflektiert.
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, den man bei der Auswahl eines Werkzeugs zur Erstellung eines Burndown-Diagramms berücksichtigen sollte, ist seine Zugänglichkeit für alle Mitglieder des Scrum-Teams. Die Sichtbarkeit des Burndown-Diagramms für das gesamte Entwicklungsteam ist ein entscheidender Motivationsfaktor. Ebenso wichtig ist ein täglicher Blick auf die Linie, die die verbleibende Arbeit anzeigt. Über das Burn-in während des Daily Scrum zu sprechen, bringt die Entwickler dazu, über ihre Arbeitsweisen und den aktuellen Stand des Produkts nachzudenken.
Wer ist verantwortlich für das Burndown-Diagramm?
Die Frage nach der Eigentümerschaft des Burndown-Diagramms ist etwas umstritten. Einerseits sollte es dem Scrum Master gehören, da es ein Werkzeug ist, 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 kommuniziert wird. Darüber hinaus könnte auch das Entwicklungsteam Anspruch auf das Eigentum erheben, da das Diagramm als internes Werkzeug fungiert.
Das Burndown-Diagramm ist eine wesentliche Kennzahl zur Bewertung der Effektivität des Entwicklungsteams und wird von allen Mitgliedern des Scrum-Teams übernommen. Deshalb sind Transparenz und Zugänglichkeit entscheidend. Allerdings ist sein eigentlicher Zweck, dem Team zu dienen. Es soll die Selbstorganisation stärken, die Motivation verbessern und ein realistisches Bild des Status der Arbeit an den ihm zugewiesenen Aufgaben geben. Daher kann theoretisch jedes Mitglied des Entwicklungsteams das Burndown-Diagramm aktualisieren.
In der Praxis fällt jedoch die Aufgabe der Aktualisierung des Burndown-Diagramms normalerweise dem Scrum Master zu. Dies geschieht insbesondere zu Beginn seiner Arbeit mit einem neuen Entwicklungsteam, wenn die Teamgeschwindigkeit noch variabel und schwer zu schä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.
Wie interpretiert man ein Burndown-Diagramm?
Wir haben das Erscheinungsbild des Burndown-Diagramms ausführlich in einem vorherigen Artikel beschrieben. Hier möchten wir nur daran erinnern, dass die X-Achse die verbleibende Zeit zur Fertigstellung der Arbeit zeigt. Auf der anderen Seite zeigt die Y-Achse die Menge an Arbeit, die noch zu erledigen ist.
Reales und ideales Burndown-Diagramm
Um ein Burndown-Diagramm zu interpretieren, ist der Schlüssel nicht nur die regelmäßige Darstellung der realen “Verbrennung”, d.h. die Ausführung der Aufgaben durch das Entwicklungsteam. Ebenso wichtig für das Bild ist der Vergleich mit der idealen Verbrennungs-Linienabnahme (Richtlinie).
Durch den Vergleich der idealen Brennlinie mit der realen Reduzierung der Arbeit, die im Burndown-Diagramm markiert ist, 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 Produkt-Ziel 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 Burndown-Diagramm zeigt das tatsächliche Tempo der Aufgaben, und die ideale Linie zeigt, mit welchem Tempo das Team arbeiten sollte, um die Aufgaben abzuschließen.
Das Burndown-Diagramm ermöglicht es auch, einen Wert zu bestimmen, der als Entwicklungsteamgeschwindigkeit bezeichnet wird, langfristig. Wir werden ihm einen separaten Artikel widmen. Hier möchten wir nur erwähnen, dass es ein Wert ist, der durch die Menge an Arbeit bestimmt wird, die während eines Sprints erledigt wurde.
Dank der Tatsache, dass das Burndown-Diagramm den Vergleich einer idealen Brennlinie mit einer realen Abnahme der Anzahl der Aufgaben veranschaulicht, ermöglicht es, das Arbeitstempo zu schätzen. Und damit das Risiko von Projektverzögerungen vorherzusehen.
Auswahl der Maßeinheit
Die Teamgeschwindigkeit wird normalerweise in Einheiten gemessen, die Story Points. definiert. Sie gibt die Anzahl der realisierten User Stories an. Diese können sehr unterschiedliche Mengen an Arbeit erfordern.
Deshalb verwenden viele Scrum-Teams eine zeitbasierte Maßnahme. Je nach Maßstab sind dies Tage oder Mannstunden. Jeder Entwickler schätzt und protokolliert dann die aufgewendete Zeit für seine Aufgaben.
Eine andere Möglichkeit ist, Aufgaben als Einheit zu übernehmen. Dies sind etwas größere Einheiten, die wiederum einen Wert in Story Points oder in Tagen oder Mannstunden zugewiesen bekommen. Es ist eine Einheit, die es dem Kunden ermöglicht, den Fortschritt der Arbeit am Produkt klarer darzustellen.
Unabhängig von der Maßeinheit ist es wichtig, das Prinzip der Berechnung der Geschwindigkeit des Entwicklungsteams zu beachten. An einem bestimmten Tag oder Sprint zählen nur Aufgaben, die tatsächlich abgeschlossen wurden. Das bedeutet, dass gestartete Aufgaben am nächsten Tag oder Sprint gezählt werden, selbst wenn nur die abschließenden Tests fehlen.
Zusammenfassung
Mit den verfügbaren Teamüberwachungswerkzeugen wird die Erstellung eines Burndown-Diagramms zu einer einfachen Aufgabe. Die wichtigste Frage ist, seine Kohärenz, Klarheit und Zugänglichkeit für alle Mitglieder des Scrum-Teams sicherzustellen.
Wenn Ihnen unser Inhalt gefällt, treten Sie unserer aktiven Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Als Projektmanagerin ist Caroline eine 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.
Scrum Guide:
- Glossar grundlegender Begriffe, Rollen und Konzepte
- Was ist Scrum?
- Scrum-Werte
- Wie implementiert man Scrum in Ihrem Unternehmen?
- Scrum-Team - was ist das und wie funktioniert es?
- Wer ist ein Product Owner?
- Die häufigsten Fehler von Product Ownern
- Wer ist der Scrum Master?
- Die häufigsten Fehler von Scrum Mastern
- Welche Statistiken und Kennzahlen sollte der Scrum Master verfolgen?
- Entwicklungsteam im Scrum
- Die häufigsten Fehler von Entwicklern
- Scrum-Artefakte
- Skalierung von Scrum
- Sprint-Backlog
- Was ist das Produkt-Backlog?
- Was sind User Stories?
- Die beste User Story mit INVEST erstellen
- Die häufigsten Fehler bei User Stories
- Benutzerstory Akzeptanzkriterien
- Schätzung und Story Points in Scrum
- Planning Poker
- Team-Schätzspiel
- Definition von Inkrement
- Scrum-Ereignisse
- Was ist ein Burndown-Diagramm?
- Vorteile und Nachteile des Burndown-Diagramms
- Kanban-Boards in Scrum und Scrumban
- Geschwindigkeit im Scrum - Tempo des Entwicklungsteams
- Tägliches Scrum
- Sprint-Planung
- Sprint-Überprüfung
- Was ist eine Sprint-Retrospektive?
- Häufige Fehler während einer Sprint-Retrospektive
- Produkt-Backlog-Pflege
- Wie erstellt man ein Burndown-Diagramm und interpretiert es?
- Was ist ein Sprint in Scrum?