In früheren Blog Beiträgen sind wir bereits auf das Thema Velocity und Story Points sowie agile Schätzmethoden eingegangen.
In diesem Beitrag wollen wir uns nun konkret mit der Releaseplanung in Scrum beschäftigen. Dabei kommen oft die folgenden zwei typischen Fragestellungen auf:
Wann wird eine bestimmte Menge an Anforderungen geliefert?
Wie viel an Funktionalität wird zu einem bestimmten Zeitpunkt geliefert?
Bei der ersten Fragestellung sprechen wir von einer Planung mit festem Umfang oder Fixed Scope, bei der zweiten von einer Planung mit festem Lieferzeitpunkt bzw. Fixed Date.
Durchaus üblich ist, dass sich Stakeholder eine Kombination dieser beiden Optionen wünschen. Wir werden daher neben den beiden Optionen auch die Kombination daraus und die damit entstehenden Herausforderungen betrachten.
Agile Releaseplanung passiert laufend
Für die Verlässlichkeit der Releaseplanung gilt grundsätzlich: Je mehr Fakten und dadurch weniger Annahmen in die Planung einfließen, desto präziser sind die Vorhersagen.
Aus diesem Grund muss der dafür verantwortliche Product Owner den Releaseplan nicht einmalig erstellen, sondern vielmehr parallel zur Entwicklung laufend durch neu gewonnene Daten anreichern und aktualisieren.
Der Releaseplan enthält somit stets sämtliche bisher gewonnenen Daten und Fakten, bei welchen es sich im Wesentlichen um die Menge der bereits umgesetzten Anforderungen (bzw. die Summe deren Story Points) sowie die bisherige Velocity handelt. Da der Releaseplan nach jedem Sprint mit diesen gemessen Daten aktualisiert wird, werden automatisch auch sämtliche Vorhersagen von Sprint zu Sprint präziser.
Für die Darstellung bzw. Visualisierung wird üblicherweise ein Release Burndown Chart angewendet, in dem sich zu jedem Zeitpunkt der Restaufwand bzw. der noch verbleibende Product Backlog (siehe folgende Abbildung) ergibt.
Die Zeitachse wird in der Regel in Sprints quantisiert, für den Aufwand werden Story Points als Einheit verwendet. Der Fortschritt des Teams ist darin indirekt über die Velocity (Anzahl der Story Points, die in einem Sprint geliefert wurden) am Ende eines Sprints erkennbar.
1. Releaseplanung mit festem Umfang
Bei diesem Szenario gehen wir von einem bereits feststehenden Umfang im Product Backlog aus und möchten “berechnen”, in wie vielen Sprints dieser Umfang voraussichtlich fertig gestellt wird.
Zunächst muss der Umfang mit Techniken wie Planning Poker geschätzt werden, wobei alle Entwickler des Umsetzungsteams eingebunden werden.
Um nun eine Aussage treffen zu können, wann das Product Backlog voraussichtlich fertig gestellt wird, wird die Velocity des Teams benötigt.
Tipp: Da derartige Planungen oftmals vor dem Entwicklungsbeginn gemacht werden, liegen noch keine evidenzbasierten Daten vor, es ist also noch keine Velocity bekannt. Daher ist es essentiell, bereits nach dem ersten Sprint diesen Plan mit der tatsächlich gemessenen Velocity neu zu berechnen, um auf eventuelle Planungsfehler so früh wie möglich reagieren zu können.
Um dennoch schon vorab eine einigermaßen realistische Aussage treffen zu können, empfehlen wir zunächst eine minimale und eine maximale Geschwindigkeit anzunehmen, in dem sich das Umsetzungsteam darüber berät, wie viele User Stories sie in den ersten Sprint einplanen würden. In dieser Diskussion ergeben sich typischerweise ein Minimal- und ein Maximalwert, welche als Ausgangsbasis dienen.
Wie formuliert man User Stories?
8 Punkte, die Sie bei der Erstellung beachten sollten!
Achtung: Beide Werte sind nur initiale Annahmen und müssen laufend durch gemessene, also evidenzbasierte Daten aktualisiert werden.
Durch das laufende Sammeln weiterer Daten über die tatsächliche Velocity ergeben sich mit der Zeit ein Durchschnittswert, welcher als primäre Grundlage für die Berechnung dient. Zusätzlich können auch die Maximal- und Minimalwerte weiterhin verwendet werden, wobei diese ebenfalls Sprint für Sprint aktualisiert werden sollten.
Die Berechnung der für die Umsetzung benötigten Sprints sieht nun wie folgt aus:
Unter Berücksichtigung von Durchschnitts-, Minimal- und Maximalvelocity ergeben sich drei Releasezeitpunkte und somit ein Korridor, in dem sich die Wahrscheinlichkeit der Lieferung bewegt, wobei die höchste und niedrigste Velocity den Best bzw. Worst Case, die durchschnittliche den Realistic Case beschreibt.
Tipp: Im Sinne der Transparenz empfehlen wir, an Ihre Stakeholder stets den gesamten Korridor zu kommunizieren - dies beugt falschen Erwartungshaltungen vor.
Mit zunehmendem Fortschritt der Entwicklung wird die Planungsgenauigkeit kontinuierlich zunehmen und sich der prognostizierte Korridor für die Fertigstellung verkleinern.
Sollte sich herausstellen, dass das voraussichtliche Lieferdatum nicht den Erwartungen entspricht und sämtliche Verbesserungen hinsichtlich Steigerung der Team Velocity bereits umgesetzt wurden, stehen folgende Optionen zur Auswahl:
- Verzicht auf die Umsetzung der nach Geschäftswert am niedrigst bewerteten Product Backlog Items
- Erweitern des Teams um weitere Entwickler
Achtung: Zusätzliche Entwickler in einem Umsetzungsteam sorgen nicht notwendigerweise für eine Zunahme der Velocity. Gerade kurzfristig kann sich die Geschwindigkeit dadurch sogar verlangsamen.
Fazit: Bei diesem Planungsszenario geht es also darum, bei feststehendem Umfang und Team, die Zeit bzw. das Lieferdatum durch laufende Planung bestmöglich zu prognostizieren. Aus der daraus resultierenden Anzahl von Sprints ergeben sich auch die Kosten.
2. Releaseplanung mit festem Datum
Wir kehren nun das Szenario um und gehen davon aus, dass ein fixes Lieferdatum in der Zukunft festgelegt worden ist, woraus sich die zur Verfügung stehende Anzahl an Sprints ergibt.
Die Frage lautet somit, wie viel an Funktionalität bis zum Release Datum geliefert werden kann.
Wie im obigen Szenario gehen wir von drei unterschiedlichen Geschwindigkeiten aus, nämlich der minimalen, der maximalen und der durchschnittlichen Velocity.
Die Berechnung sieht dann so aus:
Anzahl möglicher Sprints × Team Velocity
(höchste/niedrigste/durchschnittliche) = Story Points
Die unterschiedlichen Geschwindigkeiten markieren somit im Product Backlog drei Bereiche, deren Umsetzungswahrscheinlichkeit unterschiedlich ausfallen.
Der grüne Bereich ergibt sich aus der Berechnung des Umfangs mit der minimalen Velocity. Hier kann also davon ausgegangen werden, dass sich alle Features mit großer Wahrscheinlichkeit ausgehen werden. Idealerweise passen alle “Must Have” Features in diesen Bereich.
Im roten Bereich befinden sich die Features, die sich selbst bei dauerhaftem Halten der maximalen Velocity nicht ausgehen würden. Hier sollten sich also nur verzichtbare Features befinden, andernfalls müsste man diese höher priorisieren, was aber ein anderes Feature in diesen roten Bereich “drängen” würde.
Zwischen den beiden Bereichen ist es aus aktueller Sicht immer fraglich, ob ein Feature sich auch ausgehen wird. Je höher die aber Priorität, desto höher ist auch die Wahrscheinlichkeit, dass dieses Feature geliefert werden können.
Da auch diese Variante der Releaseplanung laufend mit gemessenen Daten aktualisiert wird, wird der unsichere Korridor in der Mitte kleiner und somit eine Aussage über den gelieferten Umfang von Sprint zu Sprint präziser.
Tipp: Diese Variante macht es besonders transparent, wie mit einer smarten Priorisierung der zu liefernden Features ein maximaler ROI erzielt werden kann, da man von Anfang an angehalten ist, im Product Backlog nach Werthaltigkeit der Features zu priorisieren und diese Priorisierung laufend zu aktualisieren, um in der vorhanden Zeit und somit auch im vorhandenen Budget ein Maximum an Wert zu erschaffen.
Sollte sich herausstellen, dass der voraussichtlich lieferbare Umfang nicht den Erwartungen entspricht und sämtliche Verbesserungen hinsichtlich Steigerung der Team Velocity bereits umgesetzt wurden, stehen folgende Optionen zur Auswahl:
- Verschiebung des Lieferdatums
- “Skalieren” des Teams um weitere Entwickler
Achtung: Zusätzliche Entwickler in einem Umsetzungsteam sorgen nicht notwendigerweise für eine Zunahme der Velocity. Gerade kurzfristig kann sich die Geschwindigkeit dadurch sogar verlangsamen.
Fazit: Bei diesem Planungsszenario geht es also darum, bei feststehendem Releasedatum und Team, den Umfang der Lieferung durch laufende Planung bestmöglich zu prognostizieren. Wenn Team und Entwicklungszeit feststehen, sind auch die Kosten bzw. das Budget definiert. In diesem Fall kann man auch von “Design to Budget” sprechen.
3. Releaseplanung mit festem Umfang und Datum
Bei diesem Szenario werden von vornherein beide Parameter fixiert. Durch die Festlegung von Umfang und Zeit wird automatisch auch die Velocity vorgegeben, die das Umsetzungsteam erreichen muss, damit der Plan funktionieren wird.
Somit gehen wir in Summe nicht von zwei, sondern von drei Konstanten aus, da die Velocity im linearen Zusammenhang von Umfang und Zeit steht - werden zwei von drei Größen fixiert, ist automatisch die dritte fixiert.
Dies ist natürlich mit äußerster Vorsicht zu genießen, da die Velocity eine empirische Größe ist, die erst am Ende eines Sprints gemessen werden kann. Als Konsequenz ist davon auszugehen, dass die tatsächliche Team Velocity von der auf Grund der beiden vorgegeben Parameter berechneten abweichen wird.
Dies ergibt sich schon alleine aus der Tatsache, dass dieses Szenario unterstellt, dass bei einer Planung mit Unsicherheit sämtliche Planungsparameter mit konkreten Werten fixiert werden können, was natürlich an der Realität völlig vorbei geht und der Grund ist, warum in den beiden ersten Planungsszenarien mit drei verschiedenen Entwicklungsgeschwindigkeiten agiert wurde.
Ist die tatsächliche Entwicklungsgeschwindigkeit gleich oder höher als die berechnete, ergeben sich keine negativen Auswirkungen für das Produkt.
Ist die tatsächliche Geschwindigkeit allerdings niedriger, ergeben sich entsprechende Herausforderungen, bei welchen zunächst die Empfehlung lautet, auf eine der beiden vorigen Varianten zu wechseln, also entweder fixes Releasedatum oder fixer Umfang.
Ist beides nicht möglich, so bleiben nur noch folgende Möglichkeiten übrig:
- Skalieren des Teams um weitere Entwickler
- Zeitgewinn durch Qualitätskompromisse
Achtung: Zusätzliche Entwickler in einem Umsetzungsteam sorgen nicht notwendigerweise für eine Zunahme der Velocity. Gerade kurzfristig kann sich die Geschwindigkeit dadurch sogar verlangsamen, weshalb vor allem bei Projekten die bereits im Verzug sind davon abzuraten ist.
Gerade dann, wenn ein Projekt in Zeitnot gerät, tendiert man dazu, Kompromisse in der Qualität einzugehen. Unzählige Softwareprojekte der Vergangenheit belegen dies. Ohne nun auf die nachhaltigen Schäden, die durch technische Schulden entstehen, eingehen zu wollen, möchten wir darauf hinweisen, dass wir schon alleine deshalb von dieser Art der Planung dringend abraten!
Fazit: Bei dieser Art der Planung geht es also darum, bei feststehendem Releasedatum, Umfang und Team die Einhaltung der bestehenden Parameter (Umfang und Zeit) durch laufende Planung bestmöglich zu überwachen um bei Abweichungen frühzeitig reagieren zu können. Da hier die komplexe Natur der Softwareentwicklung nicht berücksichtigt werden kann, raten wir entschieden davon ab.
Sie wollen Anforderungen und Wünsche erfolgreich an Entwickler kommunizieren?
Diese 8 Punkte sollten Sie dafür bei der Erstellung von User Stories wissen!
