Releases (Auslieferungen) sind Zeitpunkte, an denen ein neues oder geändertes System ausgeliefert wird und von Anwendern genutzt werden kann. Zu Beginn von Projekten werden erste Releasepläne erstellt, die darstellen, welche neuen oder geänderten Funktionen ab einem bestimmten Zeitpunkt zur Verfügung stehen sollen. Bei Scrum entsteht mit jedem Sprint ein potentiell auslieferbares Produkt-Inkrement. Die Restaufwände des verbleibenden Product Backlogs nach jedem Sprint ergeben Release Burndown Charts. Wir erklären, wie diese aussehen können und wie sie bewertet werden sollten.
Fortschrittskontrolle im Sprint
Die Abbildung zeigt, wie viel Aufwand nach einzelnen Sprints zur Realisierung von Produkt 1 übrig ist. Ist der Aufwand in Stunden angegeben, bedeutet dies, es sind zehn Sprints erforderlich, um 500 Stunden Aufwand abzuarbeiten.
Somit ist der folgende Burndown Chart realistischer:
Die nächste Abbildung beschreibt zusätzlich zu den Restaufwänden noch die sogenannte Velocity (Geschwindigkeit), die den abgearbeiteten Aufwand eines Sprints angibt.
Zunächst muss klar festgehalten werden, in welchem Aufwandsumfang sich Änderungen an bestehenden Anforderungen ergeben haben. Ebenfalls ist festzuhalten, in welchem Umfang neue Anforderungen eingebracht worden oder bestehende Anforderungen entfallen sind. Aus diesen Daten können dann detailliert Aussagen getroffen werden.
Die folgende Grafik stellt ein erweitertes Product Burndown Chart (PBC) dar. Auf der y-Achse sind die Aufwände in Stunden eingetragen. Auf der x-Achse sind die einzelnen Sprints zu sehen. Dieses Burndown Chart stellt dar, zu welchem Zeitpunkt das Produkt ausgeliefert worden wäre, wenn keine Änderungen vorhanden gewesen wären.
Die Linie Burndown zeigt, welche initial geplanten Aufgaben realisiert worden sind. "Remaining" gibt den übrigen Gesamtaufwand aus, "Changes" ist die Summe der Änderungen während der Projektlaufzeit. Jeder Linie ist in diesem Diagramm ein Trend zugeordnet.
Der Trend der Linie "Remaining" sagt aus, zu welcher Zeit die Entwicklung abgeschlossen ist, wenn weiterhin wie bisher Änderungen berücksichtigt werden. Aus den gesammelten Daten können weitere wichtige Kennzahlen errechnet werden. Für den Projektmanager ist es nun wichtig herauszufinden, wie viel vom initial geplanten Aufwand in der aktuellen Situation realisiert werden kann.
Folgende Kennzahlen sind erforderlich für weitere Planungsaussagen:
Für unser Beispiel ergeben sich für die ersten 10 Sprints folgende Kennzahlen:
In angegebenem Beispiel bedeutet dies, das Team kann pro Sprint 111,5 Stunden Aufwand abarbeiten, von diesem Aufwand sind im Durchschnitt 44,5 Stunden Änderungen und 67,0 Stunden initial geplante Aufwände.
Auch in agilen Projekten müssen Releases geplant werden. Pro Sprint sind Grobschätzungen der geplanten Funktionen erforderlich, die einen Gesamtaufwand ergeben.
Werden Veränderungen und deren Gründe am initialen Plan nicht nachvollzogen, kann kein Rückschluss auf Ursachen für einen Misserfolg gezogen werden.
Diese Variante konzentriert sich auf Änderungen von Anforderungen und auf zusätzliche Anforderungen. Wenn diese protokolliert werden, ist es für den Projektleiter ein Leichtes, vor dem Kunden den Stand des Projektes zu vertreten.
Es ist mit dieser Methode zu jeder Zeit möglich, Auskunft anhand von Trends zu Realisierungszeitpunkten zu geben und ebenfalls hat der Projektleiter genügend Wissen darüber was sich gegenüber dem initialen Plan geändert hat.
Requirements Engineering mit Scrum