Theorie "Release Planning"

Zu Beginn eines agilen Projektes kann ein Release Planning Meeting stattfinden. Dieses Meeting ist kein offizielles Scrum Meeting, das heißt, es muss nicht zwingend durchgeführt werden. Sie fragen sich vielleicht gerade, wieso wir dieses Kapitel als Letztes veröffentlichen, wo es doch am Anfang eines Projektes steht. Wir haben selbst lange überlegt und sind zu dem Schluss gekommen, dass es aus folgenden Gründen am Ende des Weblearnings besser aufgehoben ist:

• Es ist kein offizielles Scrum Event - ob Sie es durchführen wollen oder nicht, bleibt Ihnen überlassen.

• Durch das Vorwissen, welches Sie im Laufe des Kurses erlangt haben, ist dieses Kapitel leichter verständlich.

Langfristige Planung und Meilensteine¶

Diese beiden Schlagworte werden wohl eher mit traditionellem Projektmanagement in Verbindung gebracht und nicht mit agilem Projektmanagement im Allgemeinen oder Scrum im Speziellen. Dennoch spielen sie für die Releaseplanung eine wichtige Rolle. Die Releaseplanung wird nämlich auch Long-Term-Planning oder Roadmap genannt. Falls sie im Projekt Anwendung findet, dann steht sie am Beginn des ersten Sprints. Während des Meetings werden "Meilensteine" des bevorstehenden Projektes besprochen und festgelegt. Funktionen, die releast werden sollen, werden definiert und es wird geplant, wann dieser Release stattfinden soll.

Die Releaseplanung wird in der Regel durchgeführt, weil Kunden eine grobe Idee davon bekommen wollen,

• wann sie mit einem Release rechnen können,
• welche Funktionen und
• welche Kosten sie erwarten können.

Außerdem schafft die Releaseplanung ein gewisses Vertrauen zwischen dem Scrum Team, den Stakeholdern und dem Kunden. Der Kunde hat mit dem Releaseplan ein Dokument, mit dem er sich den Ablauf des Projektes visualisieren kann. Zusätzlich dazu kann der Release in einem Release Burn-Down-Chart dargestellt werden, welches Sie bereits aus dem vorherigen Kapitel kennen.

Arten des Releases¶

Wie bereits im Kapitel Sprint erklärt, muss das fertiggestellte Increment potenziell auslieferbar sein. Bei Produkten, die keine Software sind, kann es jedoch sinnvoll sein, einen Release nicht nach jedem Sprint, sondern nach einigen Sprints einen gebündelten Release durchzuführen. Je nach Wunsch des Kunden bzw. des Product Owners kann ein Release zudem funktions- oder zeitgesteuert sein - oder basierend auf beidem.

Funktionsgesteuerter Release¶

Der funktionsgesteuerte Release ist interessant, wenn der Kunde sich einen bestimmen Umfang wünscht und erst, sobald dieser Umfang erreicht wurde, ein Release stattfindet. Berechnet wird das Releasedatum, indem der gewünschte Umfang bzw. der Gesamtaufwand in Story Points durch die Velocity geteilt wird.

Zeitgesteuerter Release¶

Es sollte zeitgesteuert releast werden, wenn das Increment / das Produkt zu einem bestimmten Stichtag fertig sein muss, z. B. weil ein Event stattfindet, bei dem das Produkt vorgestellt wird. Die Gleichung hierfür ist ähnlich, wie die des funktionsgesteuerten Releases, nur dass sie umgestellt werden muss: Es müssen an dieser Stelle die Story Points berechnet werden, das heißt, man multipliziert die Velocity mit der Anzahl der Sprints bis zum Releasedatum. Anhand dieser Story Points wird herausgefunden, welche PBIs umgesetzt werden. Sollte sich erweisen, dass Zeitrahmen nicht ausreicht, kann der Liefer- und Leistungsgegenstand gekürzt werden.

Funktions- und zeitgesteuerter Release¶

Bei dem funktions- und zeitgesteuerten Release sind sowohl Umfang als auch das Veröffentlichungsdatum fix. Diese Art von Release ist heikel, da sowohl die Anzahl der Sprints, als auch die Anzahl der Story Points fix sind und deshalb die Velocity auch stabil sein muss.

Kontinuierliche Überarbeitung des Releaseplanes¶

Zu Beginn des agilen Projektes sind Planungen in vielen Fällen nur eingeschränkt möglich:

• Das Product Backlog besteht aus vielen Einträgen, die subjektiv sind und meist weitgehend angepasst werden müssen.
• Während der Projektlaufzeit kommen neue Einträge hinzu, ältere Einträge erweisen sich möglicherweise als hinfällig und werden gelöscht.
• Die Velocity der Developer, um die Einträge umzusetzen, ist zu Beginn des Projektes nicht bekannt und muss gegebenenfalls abgeschätzt werden.

Die Summe aller abgeschätzten Einträge im Product Backlog lässt ein präzises Release Planning erst zu, sobald die Velocity der Developer bekannt ist. Handelt es sich um ein neu zusammengesetztes Team oder um die erstmalige Durchführung eines Scrum-Projektes im Unternehmen, kann die Velocity erst im Verlauf des Projektes festgestellt werden. Daher ist es wichtig, dass die Releaseplanung kontinuierlich fortgeführt wird. Zusätzlich zum Release Planning Meeting zu Beginn des Projektes, empfehlen wir am Anfang jedes Sprints ein solches Meeting stattfinden zu lassen, um den Releaseplan zu aktualisieren. Durch die kontinuierliche Anpassung wird der Plan immer genauer.