Verwenden des Burndown-Diagramms zum Schätzen des Abschlussdatums eines Scrum-Projekts
Ich habe manchmal gelesen, wie man das Burndown-Diagramm verwendet, um das Datum zu schätzen, an dem das Scrum-Projekt endet. Es wird oft so beschrieben:
- Schätzen Sie alle Merkmale des Produkts und fassen Sie sie zusammen (TOTAL_STORY_POINTS).
- Führen Sie einige Sprints aus, um die Geschwindigkeit des Teams zu ermitteln
- Teilen Sie TOTAL_STORY_POINTS durch die Geschwindigkeit
Wenn es so funktionieren soll, stellt sich zunächst die Frage: Wie schätzen wir ganze Merkmale ein? Wir können kleine User Stories schätzen, weil wir den Arbeitsaufwand für deren Fertigstellung mehr oder weniger verstehen und diese Mengen daher grob vergleichen können. Zu Beginn des Projekts haben wir jedoch nur ein allgemeines Verständnis der Funktionen, aus denen unser Produkt besteht. Wir werden diese Funktionen auch bei der Kundenentwicklung ändern. Wie können wir also den anfänglichen Umfang des Projekts in Story Points abschätzen?
Antworten
Theoretisch können Sie mithilfe eines Burndown-Diagramms abschätzen, wann alle Arbeiten im Product Backlog abgeschlossen sind. In der Praxis und wie Sie sehen, funktioniert es jedoch nicht immer.
Die Verwendung eines Burndown-Diagramms zur Schätzung der Fertigstellung basiert auf einigen Annahmen, z. B. dass das Product Backlog gut verstanden und im Allgemeinen statisch ist. Dies sind jedoch normalerweise keine wahren Aussagen.
Das Team konzentriert seine Bemühungen in der Regel darauf, die Arbeit mit der höchsten Priorität ganz oben im Rückstand zu verstehen, und nur minimale Anstrengungen, wenn überhaupt, um weniger wichtige Arbeiten zu verstehen. Wenn Sie den Rückstand verringern, ist die Arbeit in der Regel größer und weniger genau definiert.
Das Product Backlog ändert sich ebenfalls häufig. Zwischen der regelmäßigen Arbeit des Product Owners zum Verständnis der Bedürfnisse der Stakeholder, dem in Sprint Reviews erhaltenen Feedback und dem Feedback aus anderen Quellen während der Verwendung des Produkts kann sich der Inhalt des Product Backlogs ändern.
In der Praxis ist die Idee, dass Sie den Abschluss eines Vorgangs vorhersagen können, von Natur aus nicht agil. In Agile ist der Bereich nicht festgelegt. Das Ende einer Anstrengung ist, wenn die Kosten für die Lieferung der nächsten Einheit den Wert überschreiten, den sie bieten würde. Indem das Team keine Anstrengungen unternimmt, um den Umfang zu definieren und festzulegen, kann es auf Feedback reagieren und die Erkenntnisse über den Betriebsbereich des Produkts einbeziehen. Ich würde vorschlagen, dass es keinen großen Unterschied zwischen dem Versuch gibt, ein Burndown-Diagramm zur Schätzung der Fertigstellung zu verwenden, und einer großen Vorausplanung, die in Domänen mit hoher Unsicherheit nicht funktioniert.
Wenn Sie bereits über die drei oben genannten Punkte verfügen, benötigen Sie kein Burndown-Diagramm, um das Abschlussdatum des Projekts abzuschätzen. Wenn Sie die Gesamtzahl der Story-Punkte durch die Geschwindigkeit dividieren, erhalten Sie eine Reihe von Sprints zurück, die (normalerweise) in Wochen unterteilt sind. Diese können Sie dann über einen Kalender verteilen und das Abschlussdatum des Projekts abrufen. Wenn Sie ein Burndown-Diagramm zeichnen, wird nur eine ideale Linie zwischen dem Start des Projekts und dem von Ihnen berechneten Abschlussdatum angezeigt. Nicht sehr nützlich.
Ein Burndown-Diagramm ist nützlich, um nicht das Fertigstellungsdatum vorherzusagen, sondern um anzuzeigen, ob Ihr tatsächlicher Fortschritt so verläuft, wie Sie es vorhergesagt haben . Sie haben eine ideale Linie für den Burndown und eine tatsächliche Linie, die Ihnen zeigt, ob Sie hinter (oben) oder vor (unten) dem liegen, was Sie ideal prognostiziert haben. Wenn Sie dies sehen, können Sie Maßnahmen ergreifen und Ihre Flugbahn korrigieren, wenn Sie dennoch zum gewünschten Datum liefern möchten.
Natürlich ist all dies nur ein Haufen idealer Dinge, von denen Sie glauben, dass sie passieren werden. Es ist eine Vorhersage, keine Vorhersage . Viele Dinge laufen anders, wenn das Projekt läuft.
Ein Burndown wird beispielsweise nicht angezeigt, wenn sich der Rückstand geändert hat. Sie verbrennen nur Story Points. Ein Burndown zeigt nicht an, ob sich die Prioritäten geändert haben oder ob Sie jetzt an dem arbeiten, von dem Sie dachten, dass Sie an oder an etwas anderem arbeiten werden. Es zeigt nur, wie viele Story-Punkte Sie verbrannt haben und wie viele noch übrig sind. Sie gehen auch davon aus, dass die Dinge gleich bleiben, sobald Sie Ihre ideale Burndown-Linie gezogen haben.
Aber natürlich ändern sich die Dinge . Wenn sich die Leute darauf konzentrieren, das richtige Produkt zu entwickeln , ändern sich die Dinge, nachdem Sie Ihre erste Prognose erstellt haben. Wenn Sie das Burndown-Diagramm schlecht verwenden, können einige das Team dazu zwingen, Anstrengungen zu unternehmen und der idealen Burndown-Linie zu folgen und nur eine Reihe von Storys oder Features durchzubrennen, die bis zum voraussichtlichen Fertigstellungstermin abgeschlossen sein sollten. Sie erhalten Waterfall jetzt im Grunde genommen mit einer großen Vorausplanung und der Annahme, dass die prognostizierten Dinge korrekt sind und jede Abweichung davon schlecht ist, was in Wirklichkeit umgekehrt ist.
Wenn Sie mehr über die Prognose von Lieferungen in Agile erfahren möchten , können Sie mit den folgenden Beiträgen beginnen:
- Wie planen Sie Liefertermine in Scrum?
- Wie schätzt du Epen ein?