Scrum-Leitfaden | 32. Vor- und Nachteile des Burndown-Charts

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

Vor- und Nachteile des Burndown Chart – Inhaltsverzeichnis:

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

Einführung

Wir haben in früheren Artikeln darüber geschrieben, was es ist, wie man ein Burndown-Diagramm erstellt und interpretiert. Heute konzentrieren wir uns auf die Vor- und Nachteile des Burndown-Diagramms. Die meisten von ihnen sind jedoch nicht in der einfachen Grafik selbst versteckt. Vielmehr beziehen sie sich auf die Möglichkeiten, das Entwicklungsteam durch das Burndown-Diagramm zu motivieren, da es die Ergebnisse seiner Arbeit beschreibt und die Selbstorganisation stärkt.

Vorteile des Burndown-Diagramms

Mit dem Brenndiagramm können Sie den Fortschritt Ihres Projekts visualisieren. Seine Lesbarkeit und Einfachheit machen es so beliebt. Deshalb ist es gut, wenn das Burn Chart nicht nur eine ständig aktualisierte Metrik ist, die in einem digitalen Projektmanagement-Tool versteckt ist. Wenn möglich, lohnt es sich, es zu einem Bezugspunkt für das Entwicklungsteam zu machen, der am physischen Arbeitsplatz sichtbar ist. Ob in Form einer Bildschirmvisualisierung oder einer handgezeichneten Skizze.

Es motiviert das Entwicklungsteam

Die Transparenz des Brenndiagramms kann es zu einem Werkzeug machen, um das Entwicklungsteam zu motivieren, effizient zu arbeiten. Das Erreichen des „Null“-Punktes in jedem Sprint kann ein ehrgeiziges Ziel des Teams werden, für das es Belohnungen gibt – gemäß den Prinzipien von Business Gamification.

Die Sichtbarkeit eines aktuellen und interessant gepflegten Burndown-Charts kann auch den Geist der Zusammenarbeit und Selbstorganisation fördern. Schließlich ist die Metrik ein Maß für die Teamarbeit. Es zeigt nicht genau, wer die geplanten Aufgaben erledigt – oder nicht – erledigt hat, sondern nur die erzielten Ergebnisse.

Es misst die tatsächlich geleistete Arbeit

Entwickler entscheiden, wie viele Aufgaben sie in einem bestimmten Sprint ausführen. Je erfahrener das Team ist, desto genauer sollte es seine Aktionen vorhersagen. Und das Bur-Down-Diagramm spiegelt den tatsächlichen Fortschritt des Sprints wider.

Der Vorteil des Burn Charts liegt also nicht so sehr darin, den objektiven Arbeitsaufwand zu messen, sondern das Verhältnis von geplanten zu erledigten Aufgaben. So lernen Entwickler nach und nach ihre Planung und können ihre Fähigkeiten immer genauer einschätzen und Wiederholungsfehler eliminieren.

Es koppelt sich mit anderen Werkzeugen

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

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

Im letzteren Fall ermöglicht beispielsweise die Verwendung des Project Scale Burndown Charts einen Vergleich des Plan- und Ist-Budgets für das gesamte Projekt.

Nachteile des Burndown-Diagramms

Trotz aller oben skizzierten Vorteile des Burndown-Diagramms kann es für das Entwicklungsteam zu einer Quelle der Verwirrung werden. Was wir häufig als „Fehler“ des Burndown-Diagramms bezeichnen, ist jedoch nicht auf Unzulänglichkeiten des Tools selbst zurückzuführen. Die im Folgenden skizzierten Probleme betreffen eher die Art und Weise der Implementierung des Burndown-Diagramms als dessen Design. Nachfolgend sind die Fehler aufgeführt, die die Darstellung des Fortschritts des Entwicklungsteams auf diese Weise beeinträchtigen 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 können. 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, müssen andere Personen Daten eingeben. Mit anderen Worten, die Entwickler haben die Aufgabenerfüllungszeit in das Diagramm eingetragen. Sie haben es vielleicht etwas verlängert oder verkürzt – entweder aus Unachtsamkeit oder um die Dinge für das Team besser zu machen. Entwickler vergessen auch manchmal, ihre Zeit zu protokollieren. Oder lassen Sie den Timer eingeschaltet. Dadurch verlängert sich die Arbeitszeit auf mehrere Stunden. Und nachdem der Fehler entdeckt wurde, ist es schwierig, seinen wahren Verlauf zu rekonstruieren.

Änderungen am Sprint Backlog

Das Sprint Backlog sollte nach dem Start eines Sprints nicht mehr geändert werden. In der Praxis treten solche Änderungen jedoch recht häufig auf. Sie resultieren aus sich ändernden Anforderungen der Stakeholder. Oder unvorhergesehene Probleme, auf die Entwickler stoßen.

Dadurch wird das Burndown-Diagramm skaliert. Dies liegt daran, dass die Zeit, die zum Erledigen der Aufgaben benötigt wird, gleich bleibt. Der Umfang der verbleibenden Aufgaben nimmt jedoch zu. Dies kann den irreführenden Eindruck erwecken, dass das Entwicklungsteam die Arbeit in einem bestimmten Sprint falsch geplant hat. Oder dass es zu langsam arbeitet.

Änderungen am Sprint Backlog können auch aus Aufgaben resultieren, deren Fertigstellung zu schnell geplant war. In einer solchen Situation beschließt das Entwicklungsteam normalerweise, die Anzahl der Aufgaben zu erhöhen. Dies wiederum kann dazu führen, dass sie nicht rechtzeitig abgeschlossen werden. Außerdem können Konflikte entstehen, wenn sich verbleibende Aufgaben aus dem vorherigen Sprint mit neuen Aufgaben überschneiden, die von Stakeholdern und Product Ownern erledigt werden sollen .

Änderungen am Product Backlog

Große Änderungen im Product Backlog können die Form des Burn-Charts stören. Und verfälschen damit stark das Bild von Arbeitsfortschritt und Teameffektivität. Dies geschieht, wenn neue User Storys erscheinen. Und diejenigen, die kurz vor der Implementierungsphase stehen, werden oft in kleinere Teile zerlegt. Es kommt auch vor, dass der Kunde auf einige Produktfunktionen verzichtet.

Daher muss man sich bei der Interpretation des Burn-Charts von Wissen und Erfahrung bei der Bewertung der Leistung des Teams leiten lassen. Berücksichtigen Sie auch die Variabilität des Backlogs. Wenn das Diagramm nicht die einzige Metrik ist, die zur Bewertung der Leistung verwendet wird, ermöglichen Ihnen die anderen Diagramme ein vollständigeres Bild des Fortschritts der Arbeit.

Zusammenfassung

Das Burndown-Diagramm kann erheblich zur Motivation des Entwicklungsteams beitragen. Dies liegt daran, dass es ein Maß für die tatsächlich an dem Plan geleistete Arbeit liefert. Darüber hinaus kann die Kombination mit anderen metrischen Tools eine Quelle wertvollen Wissens über die Arbeit des Teams und die Produktplanung sein.

Durch sorgfältige Anwendung der Scrum-Prinzipien können Sie potenzielle Probleme beim Burndown vermeiden. Das Wichtigste ist, die Tools anzupassen, um das Diagramm der Arbeit des Scrum-Teams zu folgen, sowie Änderungen am Sprint und Product Backlog zu minimieren, worüber wir in diesem Artikel mehr schreiben.

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

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