Wie Sie bei Scrum mit einem Sprint-Burn-down-Chart den Projektfortschritt steuern
Zur Visualisierung und damit auch zur Kommunikation über den Projektfortschritt gibt es bei Scrum einige Darstellungsmöglichkeiten. Neben Scrum-Boards lässt sich der Projektfortschritt mit einem Sprint-Burn-down-Chart durch den jeweils noch verbleibenden Restaufwand im Zeitverlauf dokumentieren (s. nachfolgende Abbildung nach Rubin (2014) (*Affiliate-Link). Auf der vertikalen Achse ist die ausstehende Arbeit in Stunden oder als Story-Points eingezeichnet und auf der horizontalen Achse ist die Sprint-Dauer in Stunden oder Tagen abgebildet. Die Einheit Story-Punkte hat den Vorteil, dass damit die unternehmerisch relevante Arbeit gemessen wird und nicht nur die restliche oder verbrauchte Arbeitszeit. Die Linie ist eine Treppenkurve, wobei nur komplett fertige Aufgaben (mit Status „done“) als vertikale Linie eingezeichnet werden. Noch nicht angefangene aber auch schon angefangene Aufgaben stellen einen horizontalen Linienzug dar. Das heißt, eine horizontale Linie bedeutet keinen Fortschritt. Zusätzlich kann man noch eine Trendlinie einzeichnen unter Berücksichtigung der bisherigen Velocity, um die voraussichtliche Anzahl an verbleibenden Story-Punkten im aktuellen Sprint zu prognostizieren.
Man kann natürlich das Burn-down-Chart auch als Balkendiagramm darstellen (s. nachfolgende Abbildung ). Dabei kann man es noch mit einer Skala unterhalb von Null erweitern, um zusätzlichen Aufwand zu dokumentieren, der in der initialen Planung fehlte. So kann man erkennen, wenn die Linie bzw. die Balken nicht fallen, dass ein zusätzlicher Aufwand der Grund dafür sein kann.
Eine andere Darstellung ist das Burn-up-Chart, das wiederum die (komplett!) erledigte Arbeit im Sprint visualisiert. Die Einheit kann wieder entweder Story-Punkte oder Arbeitsstunden sein.
Sieht das Team selbst alle Aufgaben als in guter Qualität abgeschlossen an, wird der Sprint mit Status „done“ (fertig) abgeschlossen. Was „done“ genau bedeutet, sollte schon am Anfang des Sprints klar definiert sein. Als Ergebnis eines Sprints soll ein potenziell auslieferungsfähiges Produktinkrement entwickelt werden, das bereits durch ein Feedback mit dem Kunden getestet wurde. Anschließend werden das Produktinkrement im Sprint-Review und der Prozess in der Sprint-Retrospectives überprüft, ob die jeweiligen Anforderungen erfüllt und/oder Änderungen notwendig sind. Das heißt, mit dem Sprint-Review wird die Unsicherheit abgebaut, was entwickelt werden soll und mit den Sprint-Retrospectives die Unsicherheit, wie es entwickelt werden soll.
Literatur:
(*Affiliate-Links)