---

Was ist ein Scrum-Release-Plan? Das könnte Sie überraschen!

Er zeigt grobe Planung über mehrere Sprints, im Beispiel meist drei bis zwölf. Sprints sind Zeitfenster; Inkremente nutzbare Ergebnisse. Mehrere Inkremente können innerhalb eines Sprints entstehen.

Der Plan beschreibt Erwartungen daran,

• welche Funktionen umgesetzt werden,
• in welcher Reihenfolge und wann.

Er dient auch als Maßstab für Steuerung und Fortschritt. Für tatsächliche Produktionsbereitstellungen hat er zwei Zielarten:

• Meilensteinlieferungen schaffen vor Projektende Kundennutzen mit einem zwischen Product Owner, Kunde und Stakeholdern vereinbarten Teilumfang.
• Die abschließende Lieferung umfasst alle bekannten Wünsche und Anforderungen von Kunden und Stakeholdern.

Vor der Erstellung sind zu berücksichtigen:

• Ein priorisiertes und geschätztes Product Backlog,
• die gemessene Velocity des Teams (bei neuen Teams geschätzt oder aus ähnlichen früheren Projekten abgeleitet),
• Erfolgskriterien der Kunden, etwa Termin, Umfang und verfügbare Menschen im Budget.

Wegen der engen Verbindung zum Backlog verwaltet und pflegt der Product Owner die Release-Pläne.

Nach Kundenbedarf und Priorität dient der Plan einem von drei Zielen:

• Funktionsbasierte Release-Planung
• Terminbasierte Release-Planung
• Funktions- und terminbasierte Release-Planung (Am häufigsten)

Funktionsbasierte Release-Planung

Was wir wissen: Velocity und gewünschte Funktionen.
Was wir nicht wissen: Wie lange dauert die Lieferung dieser Funktionen?

Bei funktionsbasierten Plänen (mehr dazu unter Scrum-Release-Planung) teilen wir die Summe der gewünschten Story Points durch die Velocity. Auf ganze Sprints aufgerundet ergibt das eine erste Prognose bis Meilenstein oder Abschluss. Umfangs- und Velocity-Annahmen werden fortlaufend geprüft und der Plan entsprechend erstellt.

Terminbasierte Release-Planung

Was wir wissen: Velocity und gewünschter Liefertermin.
Was wir nicht wissen: Welche Funktionen schaffen wir bis zur Frist?

Velocity mal Sprints bis zum Termin ergibt die geschätzten lieferbaren Punkte. Darauf basiert der terminbezogene Plan.

Funktions- und terminbasierte Release-Planung

Was wir wissen: Velocity, gewünschte Funktionen und deren Liefertermin.
Was wir nicht wissen: Kann das Team die Funktionen bis zur Frist liefern?

Velocity mal verbleibende Sprints ergibt die geschätzten Punkte. Übersteigt diese Zahl den gewünschten Umfang, scheint er laut aktueller Prognose zu passen. Unsicherheit und Änderungen bleiben bestehen.

Andernfalls sind Umfang, Termin und Kapazität abzuwägen. Mehr Menschen erhöhen Velocity nicht automatisch und können zunächst bremsen. Die ältere Neun-Personen-Regel ist keine aktuelle feste Grenze; Teams haben typischerweise 10 oder weniger Menschen. Ein weiteres Team kann parallel helfen; am selben Produkt teilen sie Product Owner, Goal, Backlog und DoD.

Der Plan bleibt lebendig. Neues Wissen, hinzugefügte, entfernte oder geänderte Stories und Schätzungen beeinflussen ihn. Prüfen und aktualisieren Sie ihn regelmäßig.