Scrum Guide | 32. Vorteile und Nachteile des Burndown-Diagramms

Das Burndown-Diagramm hat viele Vorteile. Es ist eines der wichtigsten Metrik-Tools in Scrum aus mehreren Gründen. Es ist einfach zu erstellen, zu skalieren und zu lesen. Allerdings hat es auch Nachteile, die es nicht zu einem universellen Tool machen. Im heutigen Artikel behandeln wir das Thema der Nachteile und Vorteile des Burndown-Diagramms.

Vorteile und Nachteile des Burndown-Diagramms – Inhaltsverzeichnis:

1. Einführung
2. Vorteile des Burndown-Diagramms
3. Nachteile des Burndown-Diagramms
4. Zusammenfassung

Einführung

Wir haben in früheren Artikeln über was es ist, wie man ein Burndown-Diagramm erstellt und interpretiert geschrieben. Heute werden wir uns auf die Vorteile und Nachteile des Burndown-Diagramms konzentrieren. Die meisten von ihnen sind jedoch nicht im einfachen Diagramm selbst verborgen. Vielmehr stehen sie im Zusammenhang mit den Möglichkeiten, das Burndown-Diagramm zu motivieren das Entwicklungsteam, da sie die Ergebnisse ihrer Arbeit beschreiben und die Selbstorganisation stärken.

Vorteile des Burndown-Diagramms

Das Burndown-Diagramm ermöglicht es Ihnen, den Fortschritt Ihres Projekts zu visualisieren. Seine Lesbarkeit und Einfachheit machen es so beliebt. Deshalb ist es eine gute Idee, dass das Burndown-Diagramm nicht nur eine ständig aktualisierte Metrik ist, die in einem digitalen Projektmanagement-Tool verborgen ist. Wenn möglich, ist es sinnvoll, es zu einem Referenzpunkt für das Entwicklungsteam zu machen, der am physischen Arbeitsplatz sichtbar ist. Sei es in Form einer Bildschirmvisualisierung oder einer handgezeichneten Skizze.

Es motiviert das Entwicklungsteam

Die Transparenz des Burndown-Diagramms kann es zu einem Werkzeug machen, um das Entwicklungsteam zu motivieren, effizient zu arbeiten. Das Erreichen des “Null”-Punkts in jedem Sprint kann ein ehrgeiziges Ziel des Teams werden, für das Belohnungen vergeben werden – gemäß den Prinzipien der Geschäftsgamification.

Die Sichtbarkeit eines aktuellen und interessant gepflegten Burndown-Diagramms kann auch den Teamgeist und die Selbstorganisation fördern. Immerhin ist die Metrik ein Maß für Teamarbeit. Sie zeigt nicht genau, wer die geplanten Aufgaben abgeschlossen hat oder nicht, sondern nur die erzielten Ergebnisse.

Es misst die tatsächlich geleistete Arbeit

Entwickler entscheiden, wie viele Aufgaben sie in einem bestimmten Sprint erledigen werden. Je erfahrener das Team ist, desto genauer sollten sie ihre Handlungen vorhersagen können. Und das Burndown-Diagramm spiegelt den tatsächlichen Fortschritt des Sprints wider.

Somit besteht der Vorteil des Burndown-Diagramms nicht so sehr darin, die objektive Menge an geleisteter Arbeit zu messen, sondern das Verhältnis von geplanten zu abgeschlossenen Aufgaben. So lernen die Entwickler allmählich, wie sie diese planen können, und können ihre Fähigkeiten immer genauer einschätzen und wiederholte Fehler beseitigen.

Es lässt sich mit anderen Tools kombinieren

Einer der wesentlichen Vorteile des Burndown-Diagramms betrifft seine Vielseitigkeit in der Kombination mit anderen Tools. Die folgenden Tools können angewendet werden:

• Analyse der Arbeit des Entwicklungsteams
• Visualisierung des Fortschritts der Arbeit am Produkt
• Schätzung des Projektbudgets

Zum Beispiel ermöglicht die Verwendung des Projekt-Skala-Burndown-Diagramms im letzteren Fall einen Vergleich des geplanten und tatsächlichen Budgets für das gesamte Projekt.

Nachteile des Burndown-Diagramms

Trotz aller oben genannten Vorteile des Burndown-Diagramms kann es eine Quelle der Verwirrung für das Entwicklungsteam werden. Was wir häufig als “Mängel” des Burndown-Diagramms bezeichnen, liegt jedoch nicht an Unvollkommenheiten des Tools selbst. Die unten skizzierten Probleme betreffen eher die Art und Weise, wie das Burndown-Diagramm implementiert wird, als dessen Design. Im Folgenden sind die Mängel aufgeführt, die die Darstellung des Fortschritts des Entwicklungsteams auf diese Weise stören können.

“Der menschliche Faktor”

Diagramme können kein absolutes Maß für den Fortschritt eines Teams sein. Sie sind nur Werkzeuge, die auf unterschiedliche, mehr oder weniger geschickte Weise angewendet werden. Wir können dies als Nachteil (oder Vorteil) nicht nur des Burndown-Diagramms, sondern auch anderer Maßnahmen zur Teamleistung betrachten.

Um ein Burndown-Diagramm zu erstellen, benötigen Sie andere Personen, um Daten einzugeben. Mit anderen Worten, die Entwickler tragen die Zeit für den Abschluss von Aufgaben im Diagramm ein. Sie könnten diese Zeit ein wenig verlängert oder verkürzt haben – entweder durch Unaufmerksamkeit oder um es dem Team besser zu machen. Entwickler vergessen auch manchmal, ihre Zeit zu protokollieren. Oder lassen den Timer laufen. Dies führt dazu, dass die Arbeitszeit auf mehrere Stunden ausgedehnt wird. Und nach Entdeckung des Fehlers ist es schwierig, den tatsächlichen Verlauf zu rekonstruieren.

Änderungen am Sprint-Backlog

Das Sprint-Backlog sollte nach Beginn eines Sprints nicht geändert werden. In der Praxis treten jedoch solche Änderungen recht häufig auf. Sie resultieren aus sich ändernden Anforderungen der Stakeholder. Oder unvorhergesehenen Problemen, mit denen die Entwickler konfrontiert sind.

Dies führt dazu, dass das Burndown-Diagramm skaliert wird. Dies liegt daran, dass die für den Abschluss der Aufgaben benötigte Zeit gleich bleibt. Allerdings steigt die Anzahl der verbleibenden Aufgaben. Dies kann den irreführenden Eindruck erwecken, dass das Entwicklungsteam die Arbeit für einen bestimmten Sprint falsch geplant hat. Oder dass es zu langsam arbeitet.

Änderungen am Sprint-Backlog können auch aus Aufgaben resultieren, die zu schnell für den Abschluss eingeplant wurden. In einer solchen Situation entscheidet das Entwicklungsteam normalerweise, die Anzahl der Aufgaben zu erhöhen. Dies kann wiederum dazu führen, dass sie nicht rechtzeitig abgeschlossen werden. Auch können Konflikte aus der Überlappung verbleibender Aufgaben aus dem vorherigen Sprint mit neuen Aufgaben entstehen, die von Stakeholdern und Product Owners eingeplant sind.

Änderungen am Produkt-Backlog

Große Änderungen im Produkt-Backlog können die Form des Burndown-Diagramms stören. Und somit das Bild des Arbeitsfortschritts und der Team-Effektivität stark verfälschen. Dies geschieht, wenn neue User Stories erscheinen. Und die, die sich in der Nähe der Implementierungsphase befinden, werden oft in kleinere Teile zerlegt. Es kommt auch vor, dass der Kunde auf einige Produktfunktionen verzichtet.

Daher muss man bei der Interpretation des Burndown-Diagramms wissen und Erfahrung in der Bewertung der Teamleistung berücksichtigen. Und auch die Variabilität des Backlogs in Betracht ziehen. Wenn das Diagramm nicht die einzige Metrik ist, die zur Bewertung der Leistung verwendet wird, ermöglichen die anderen Diagramme, ein vollständigeres Bild des Arbeitsfortschritts zu sehen.

Zusammenfassung

Das Burndown-Diagramm kann erheblich zur Motivation des Entwicklungsteams beitragen. Dies liegt daran, dass es ein Maß für die tatsächlich geleistete Arbeit am Plan bietet. Darüber hinaus kann seine Kombination mit anderen Metrik-Tools eine wertvolle Wissensquelle über die Arbeit des Teams und die Produktplanung sein.

Durch sorgfältige Anwendung der Scrum-Prinzipien können Sie potenzielle Probleme mit dem Burndown-Diagramm vermeiden. Das Wichtigste ist, die Werkzeuge zur Führung des Diagramms an die tatsächliche Arbeit des Scrum-Teams anzupassen und Änderungen am Sprint- und Produkt-Backlog zu minimieren, worüber wir in diesem Artikel mehr schreiben.

Wenn Ihnen unsere Inhalte gefallen, treten Sie unserer aktiven Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.