Frameworks für Agile Release-Planung
Agile Release-Planung erfordert mehr als Termine in einem Kalender. Sie benötigen ein starkes Product Backlog sowie eine gemeinsame Produktvision. In dieser Anleitung geben wir einen umfassenden Überblick über den Prozess und hilfreiche Frameworks, um die Arbeit zu erledigen.
Meine Managerin Celia kam gelegentlich an meinem Schreibtisch vorbei und fragte: „Wann wirst du fertig sein?“ Hinter ihrem lässigen Auftreten fragte sie wirklich: „Also Kevin, ich habe dir drei Scrum-Teams gegeben, um diese Anwendung zu erstellen. Wann bekomme ich mein Geld von ihnen?
Ein unerfahrener Produktmanager könnte geantwortet haben: „Wir sind agil. Wir lassen los, wenn wir bereit sind.“ Zum Glück war ich kein Neuling und habe auf Celia geantwortet“, basierend auf Daten aus den letzten Sprints — und was im Product Backlog noch übrig ist — zeigt mein Release-Plan mit hoher Zuversicht auf die Veröffentlichung in sechs Wochen mit dem Potenzial, früh in nur vier Wochen zu veröffentlichen.“
Mein Vertrauen erfüllte Celia und wurde durch all die Arbeit unterstützt, die ich mit meinen Teams geleistet habe, um einen soliden Release-Plan für mein Produkt zu entwickeln und aufrechtzuerhalten. In meinen frühen Jahren als Produktmanager war es eine entmutigende Aufgabe, einen Release-Plan zu erstellen. Sobald ich die Mechanismen und Rhythmen von Release-Plänen besser verstanden hatte, wurde das Erstellen und Verwalten viel einfacher. Für diejenigen unter Ihnen, die eine „Celia“ in Ihrem Leben haben (wir alle), wissen Sie, dass sich die harte Arbeit, die Sie für den Aufbau und die Pflege eines Release-Plans aufgewendet haben, absolut lohnt.
Was ist ein Release-Plan?
Ein Release-Plan ist eine übergeordnete Prognose, die in der Regel über mehrere Sprints verteilt ist und beschreibt, wie Sie durch die Veröffentlichung Ihres Produkts einen Mehrwert erzielen möchten. Ein Release-Plan ist ein unschätzbares Werkzeug, da er diese Fragen beantwortet:
- Welche Product Backlog Items werden in welchem Sprint bearbeitet?
- Was ist in der nächsten Version?
- Wann wirst du fertig sein?
Release-Pläne sind Taktiken auf mittlerer Ebene am Zeithorizont der agilen Planung, die sowohl Roadmaps zum Leben erwecken als auch dem Product Backlog eine wertvolle Zeitdimension hinzufügen. Ein Release-Plan deckt mehrere Sprints ab und umfasst häufig mehrere Scrum-Teams und / oder Teams an mehreren Standorten. Unabhängig vom Umfang ist die Erstellung eines Release-Plans eine Zusammenarbeit zwischen Produktmanager, Product Owner, ScrumMaster, Scrum-Teams und Stakeholdern. Normalerweise verwende ich gerne einen Zeithorizont von zwei bis vier Monaten für Release-Pläne. Release-Pläne, die zu weit in die Zukunft prognostizieren, beinhalten zu viel Variabilität und inhärentes Zeitplanrisiko. Je kürzer die Pläne sind, desto schneller geben Sie den Wert frei und desto mehr Vertrauen haben Sie in Ihre Veröffentlichungstermine.
Releases können mit einer festen Kadenz oder mit einem festen Umfang erfolgen – aber nicht beides. Wenn der Umfang des Releases festgelegt ist, erzeugt der Plan die erwartete Anzahl von Sprints, die erforderlich sind, um die für das Release geplanten Product Backlog-Elemente bereitzustellen. Wenn das Datum festgelegt ist, gibt der Veröffentlichungsplan alternativ an, was wahrscheinlich in der nächsten Version mit festem Datum enthalten sein wird. Das Gute ist, dass die letzten Elemente, die in der Version geliefert werden — und höchstwahrscheinlich bei Bedarf gekürzt werden —, die am wenigsten wichtigen Elemente sein sollten.
Beginnen Sie mit der Produktvision & Product Backlog
Um einen guten Release-Plan zu haben, benötigen Sie ein starkes Product Backlog. Integraler Bestandteil eines starken Product Backlogs ist eine gemeinsame Produktvision zwischen den Produktmanagern, Product Ownern und Scrum-Teams. Die Produktvision hilft Ihnen, das große Ganze im Fokus zu behalten, während Sie Ihren Release-Plan erstellen und die Dinge priorisieren, die für Ihre Kunden und das Unternehmen wirklich wichtig sind.
Es gibt zwei Frameworks, die ich verwende, um eine Produktvision unter den Scrum-Teams zu entwickeln und zu kommunizieren. Welches Sie wählen, hängt normalerweise davon ab, ob die Scrum-Teams gemeinsam oder verteilt sind. Für ein Co-located Scrum Team ist Product Box die beste Wahl. Wenn verteilt, verwende ich gerne unsere Shark Tank Vision Vorlage, beeinflusst von McKennas und Moores Elevator Pitch Framework und unten gezeigt.
Profi-Tipp: Zusätzlich zur Produktvision sollten Sie eine Vision für die nächste Version entwickeln. Eine Release-Vision ist besonders hilfreich, wenn die Version einen neuen Markt, eine neue Person oder neue Funktionen anspricht.
Zusätzlich zu einer Produktvision sollte Ihr Product Backlog drei Elemente enthalten, die für den Release-Plan entscheidend sind:
- Artikel sind gut verfeinert (d. H., die die Bereitschaftskriterien des Scrum-Teams erfüllen).
- Elemente sind entsprechend kleiner als ein Sprint. Kleiner ist besser.
- Elemente werden nach Wert priorisiert.
Pro-Tipp: Es gibt zwei sehr kollaborative Frameworks, die ich mit Kunden und Stakeholdern verwende, um das Product Backlog basierend auf dem Wert zu priorisieren: Beschneiden Sie den Produktbaum und 20/20 Vision.
Das agile Release-Planungsereignis
Sobald Sie die Produktvision, eine Release-Vision und ein fertiges Product Backlog festgelegt haben, sollten Sie ein Release-Planungsereignis planen. Agile Release Planning Events sind kollaborative Events, bei denen sowohl Scrum-Teammitglieder als auch Stakeholder die Ärmel hochkrempeln und Entscheidungen darüber treffen, was als Teil des nächsten Releases entwickelt werden soll. Sie treten normalerweise auf, nachdem die Roadmap entwickelt wurde.
Ein Release-Planungsereignis kann einen oder mehrere Tage umfassen. Da die agile Release-Planung eine große Investition von Zeit und Personal sein kann, sollten Sie sicherstellen, dass Sie genügend Zeit haben, um sich richtig auf diese Aktivität vorzubereiten. Planen Sie also, während der Veranstaltung Spaß zu haben, und denken Sie daran, zu feiern, wenn alles vorbei ist!
Unabhängig davon, ob Sie mit einem oder zehn Scrum-Teams planen, bleibt die Struktur eines guten Release-Planungsereignisses gleich:
-
- Teilen Sie die Vision für das nächste Release. Der Produktmanager, Product Owner oder Chief Product Owner wird das /die Scrum-Team(e) an die Release-Ziele erinnern, die Release-Vision teilen und erklären, wie diese Version Fortschritte in Richtung der gesamten Produktvision macht.
- Entscheiden Sie sich für ein festes Datum oder einen festen Umfang Jeder Ansatz ist in Ordnung, aber es ist wichtig, für Ihr Unternehmen zu entscheiden, was am wichtigsten ist: freigabe zu einem bestimmten Zeitpunkt (um einen Marktrhythmus wie eine Messe zu erreichen) oder mit einer Reihe von Funktionen (alles, was in einem Kundenworkflow enthalten ist).
- Überprüfen Sie die wichtigsten Elemente in Ihrem Product Backlog und legen Sie eine Schnittlinie fest. Eine Cutline legt fest, wie tief in das Product Backlog Sie in dieser Version liefern möchten.
- Ordnen Sie jeden Sprint zu. Bei der Arbeit mit mehreren Scrum-Teams zieht jedes seine „lokale“ Liste von Elementen aus dem einzelnen Product Backlog. Planen Sie anhand von Velocity-Daten für jedes Scrum-Team, welche Elemente wahrscheinlich in jedem Sprint geliefert werden.
- Risiken und Abhängigkeiten erfassen. Nehmen Sie sich Zeit, um wichtige Annahmen, Risiken und Abhängigkeiten hervorzuheben, die sich auf die Bereitstellung der Version auswirken könnten. Transparenz ist wichtig und wird hilfreich sein, wie Sie das Release-Fenster kommunizieren.
Beantwortung der Frage „Wann wird es gemacht?“
Nachdem Sie die ganze harte Arbeit geleistet haben, ist es an der Zeit, Celias Frage zu beantworten, indem Sie das Veröffentlichungsfenster schätzen. Ein Freigabefenster ist eine Reihe möglicher Liefertermine, die auf empirischen Daten basieren.
Es gibt eine Vielzahl von Gründen, warum Sie ein Release-Fenster anstelle eines bestimmten Datums anbieten möchten. Geschwindigkeiten ändern sich im Laufe der Zeit. Ein Freigabefenster veranschaulicht diese Unsicherheit und erkennt an, dass Ihr Plan eine Prognose und keine genaue Verpflichtung ist. Wenn Sie jeden Sprint einen Mehrwert liefern, wird das Release-Fenster enger, wenn Unbekannte bekannt werden und Risiken gemindert oder beseitigt werden.
Um ein Freigabefenster zu berechnen, gehen Sie folgendermaßen vor:
-
- Schätzen Sie eine hohe „Steady-State“ -Geschwindigkeit. Dadurch wird der früheste voraussichtliche Liefertermin festgelegt.
- Schätzen Sie mit einer niedrigen „Steady-State“ -Geschwindigkeit neu. Dadurch wird der späteste voraussichtliche Liefertermin festgelegt.
- Berechnen Sie das Freigabefenster. Dies ist der Unterschied zwischen hohen und niedrigen stationären Geschwindigkeiten.
- Fügen Sie einen geeigneten Puffer hinzu. Dies ist eine Funktion der verschiedenen Risiken und Abhängigkeiten innerhalb Ihres Plans. Es kann durch Zeit oder einen Vertrauensfaktor ausgedrückt werden. Ich empfehle einen Puffer, der den identifizierten Risiken und Abhängigkeiten entspricht. Wenn Sie beispielsweise viele Risiken und Abhängigkeiten haben, haben Sie mehr Puffer. Wenn es weniger Risiken und Abhängigkeiten gibt, verwenden Sie weniger Puffer.
Machen Sie zum Schluss einen Schritt zurück und analysieren Sie Ihren Release-Plan relativ zu Ihrer Roadmap. Denken Sie daran, dass eine gute Roadmap die Berücksichtigung von Marktfenstern, Rhythmen oder Segmenten umfasst, auf die Sie abzielen möchten. Basierend auf Ihrer Roadmap müssen Sie möglicherweise das Product Backlog entsprechend anpassen, um sicherzustellen, dass Ihre Version den Einschränkungen oder Zielen der Roadmap entspricht.
Der nächste Schritt
Die Erstellung dieses ersten Release-Plans kann harte Arbeit sein. Sobald Sie sich jedoch im Rhythmus der Entwicklung und Pflege des Release-Plans Ihres Produkts befinden, werden Sie ihn bald als unschätzbares Artefakt in Ihrer Produktmanagement-Toolbox finden. Wenn Sie mehr über die Entwicklung eines Release-Plans für Ihr Produkt erfahren möchten, kontaktieren Sie uns für Hilfe. Gerne sprechen wir mit Ihnen weiter und beraten Sie bei der Integration von Release-Plänen für Ihr Unternehmen.