Release Backup
Das Release Backup ist ein Planungstool, das bei der Aufteilung der Funktionalitäten eines Produktes unterstützt und hilft diese Entwicklung der Funktionalitäten im Zeitverlauf über mehrere Releases zu verteilen.
Die Bezeichnung für die Release Planung unterscheiden sich innerhalb der Organisationen. Sie wird auch als langfristige Produktplanung oder meilensteingesteuerte Planung bezeichnet. Wenn nach jedem Sprint eine Auslieferung erfolgt, kann die Aufteilung in Releases auch als Sprint Mapping bezeichnet werden.
Die Fragen der Stakeholder, die mit der Release Planung beantwortet werden:
- "Wann werden wir welche Inkremente geliefert bekommen?"
- "Welche Funktionen werden wir bis zum Ende des Jahres bekommen?"
- "Bis wann müssen wir wieviel Geld bereitstellen?"
Mit einem Release werden Funktionalitäten an den Kunden ausgeliefert. - So zumindest der Zusammenhang, in dem ich den Begriff Release hier verwende.
Je nach Vertragssituation, Stakeholder Wünschen und Produkteigenschaften, muss eine Entscheidung über die Kadenzen mit denen die Leistungen an den Kunden ausgeliefert werden, vereinbart werden. Die agilen Prinzipien empfehlen diese Auslieferungszyklen möglichst klein zu halten. Einerseits, um frühzeitig ein Feedback zu erhalten und so Fehlentwicklungen zu vermeiden, andererseits damit die (Teil-)Produkte am Markt möglichst früh einen Deckungsbeitrag generieren können.
Denkbar sind folgende Kadenzen:
Bei manchen Produktentwicklungen werden Minimum Relesable Features (MRFs) festgelegt. Es handelt sich um minimal freigegebene Funktionen, also um die Funktionen, die pro Release mindestens als Inkremente erstellt werden müssen. Das ganze Konzept dieser MRFs ist etwas schwierig, weil es nur dann realisierbar ist, wenn die Funktionen in einem Product Backlog alle vergleichbar sind. Außerdem sollen die User Stories, die in einer Timebox erstellt werden, ja nach Möglichkeit verbindlich sein. Das MRFs Konzept beinhaltet das Risiko, dass Timeboxes über die bearbeitbaren Anforderungen hinaus vollgestopft werden, so nach dem Motto: Vielleicht sind sie ja schneller. Wichtig sind ja sowieso nur die MRFs.
Ein Produkt, das in dem Portfolio Backlog steht, ist zumeist nur sehr ungenau beschrieben. Die Beschreibung wird eben ausreichend sein, um die wirtschaftlichen Kriterien zu überprüfen und daraus die Priorität zu bestimmen, die das Produkt in Relation zu den anderen Produkten im Portfolio Backlog haben.
Wahrscheinlich werden einige Funktionalitäten beschrieben sein und andere eher unklar bestehen. Die Genauigkeit der Schätzung für die einzelnen Funktionen und für den Aufwand der Produkterstellung kann sehr unterschiedlich sein. Das ist immer davon abhängig, wie genau der Auftraggeber und das eigene Unternehmen eine Kosten-Leistungsschätzung haben möchte und welche Kriterien in dem Unternehmen zur Wirtschaftlichkeitsprüfung von Investitionen zugrunde gelegt werden.
Für die Erstellung des Release Backups ist das zunächst nicht wichtig. Wir nehmen die Informationen die bisher erarbeitet wurden. Für das Release Backlog werden sie weiter entwickelt, überprüft und verfeinert.
Zunächst wird festgelegt:
- Wie viele Releases gemacht werden sollen.
- Wie lange die einzelnen Releases dauern sollen. Die Dauer der Releases kann auch als Timebox für die Produktentwicklung verstanden werden.
- Wie viele Aufwandspunkt, z.B. Story Points innerhalb eines Release abgearbeitet werden kann. Dafür können z.B. die Erfahrungen mit der Team Velocity genutzt werden.
Wenn zusätzliche Anforderungen dazu gekommen sind, werden diese Anforderungen ergänzt. Anders Ausgedrückt: es müssen neue User Stories geschrieben werden. Auch der für das Gesamtprojekt geschätzte Aufwand muss für jede Funktion oder User Story neu geschätzt werden.
Die Prioritäten, die jetzt aus Perspektive der Funktionalitäten basierend auf dem Wert der jeweiligen Funktionalität aus Stakeholder Sicht ermittelt werden, sind ausschlaggebend für die Reihenfolge, mit der die Funktionalität in den Releases bearbeitet wird.
Daraus entsteht ein Release Plan, der den Leistungserstellungsprozess des Produktes in mehrere große Einheiten unterteilt. Genau wie alle anderen Backlogs muss dieses Backlog regelmäßig überprüft und an die neueste Entwicklung angepasst werden.