.st0{fill:#FFFFFF;}

Scrum Einführung

Release Planung im Detail

 April 6, 2018

von  Sebastian

​In diesem Artikel zeige ich Ihnen, wie man die Release Planung in Scrum behandeln kann. Interessanter Weise denken viele Personen, dass diese zwingend notwendig ist. Ist sie aber nicht und ich möchte dazu auch ein wenig mit den Vorurteilen und falschen Annahmen zur Release Planung in Scrum aufräumen.

​Was ist ein Release?

​Als ein Release verstehen wir eine Version einer Software. Wenn wir also eine fertige, veröffentlichte Version einer Software ​erzeugt haben, dann bezeichnen wir diese als Release. Diese Version ist dann in der Regel immer für einen Kunden - wo auch immer der angesiedelt ist - verfügbar.

​Release Planung in Scrum

Release Planung in Scrum

​Im Folgenden gehe ich nur auf die Möglichkeiten der Release Planung in Scrum ein. ​Dabei werden wir zum einen ein Blick darauf werfen, wann wir diese Release Planung überhaupt brauchen. Zum anderen schauen wir uns genau an, welche Möglichkeiten Sie in Scrum haben, um eine Release Planung durchzuführen.

​Scrum braucht keine Releases

​Grundsätzlich braucht Scrum keine Releases. Scrum hat den Anspruch in jedem Sprint etwas zu entwickeln, wobei der Nutzen die Kosten übersteigt. Wenn das so ist, können wir im Sprint Review überprüfen, in wie weit das dem Kunden zusagen, überlegen ob wir Anpassungen vornehmen wollen und dann in die nächste Runde gehen.

Das ist zum einen nicht immer ​realistisch, wenn Sie Ihre Integrations- und Deployment-Strategien nicht soweit entwickelt haben, dass das möglich ist. Zum anderen müssen Sie nicht zwangsläufig Software entwickeln, sondern können auch Scrum in der Hardware oder anderen Bereichen benutzen. Es gibt also durchaus die Situationen, in denen Sie sich mit einer Release Planung in Scrum auseinander zusetzen.

Wenn wir es besonders einfach ​betrachten wollen, dann finden Sie in meinem Artikel agil und Lean übertrieben einfach einen ersten Ansatz, sich dem Thema zu nähern. Je ungewisser die ​Rahmenbedingungen sind bei Ihnen sind, desto mehr sollten Sie auf schnelle Releases Wert legen, nur so können Sie das Risiko verringern, das auf einem unebständigen Markt existert.

​​Hohe Anforderungen, wenn der Sprint das Release ist

​Wer pro Sprint immer der Mehrwert an den Kunden liefern ​kann, ist gut dran. Viele Unternehmen und Teams ​befinden sich noch lange nicht auf so einer Ebene. Deswegen kann man den Gedanken der Release Planung (mindestens als Übergang) weiterführen.

Bedenken Sie, dass Sie praktisch in einem Sprint alles das machen müssen, um wirklich eine fertige, getestete und releaste Version zu erzeugen. Ja, das ist eigentlich nichts neues in Scrum, aber viele Teams sind da schlicht noch nicht. Das muss nicht schlimm sein, aber das ist grundlegend das Ziel von Scrum.

​Wann Sie doch eine Release Planung in Scrum benötigen

​Wie im vorherigen Absatz besprochen, brauchen Sie wenigstens dann eine Release Planung, wenn Sie eben nicht in der Lage sind, jeden Sprint eine vollständige Version zu erzeugen. Dann benötigt der Product Owner einen Überblick, wann und wie er mögliche Releases an den Kunden ausliefern kann. Zudem muss der Product Owner nicht jeden Sprint releasen.

Wenn Sie ​diese Szenarien haben und abdecken wollen, dann können und müssen Sie sich über eine Release Planung Gedanken machen.

​Release nach Zeit

​Oft haben Sie als Product Owner ein zeitliches Ziel. Sie können also einen Termin, wann die Version verfügbar sein soll, nicht verschieben. Zum Beispiel weil der Kunde etwas auf einer Messe zeigen möchte und deshalb die Software oder das Produkt, das Sie entwickeln, nicht später nutzen kann, als zu einem bestimmten Termin.

​Nutzen Sie Ihr abgeschätzes Backlog, das bereits D.E.E.P. sein sollte, dann haben Sie die Schätzungen für alle Einträge bereits vorliegen. Ansonsten können Sie mit agilem Schätzen diese Einträge ​nachträglich noch entsprechen bewerten und in eine Reihenfolge bringen.

​Jetzt brauchen Sie nur folgendes zu tun, um eine erste Prognose zu bekommen. Sie schauen sich an, wann Ihr zeitliches Ziel erreicht sein muss und wieviele Sprints Sie bis dahin noch durchführen werden. Danach schauen Sie sich die Velocity des Teams pro Sprint an. Jetzt können Sie die Anzahl der Sprints einfach mit der Velocity (Durchschnitt) multiplizieren und Sie bekommen eine Zahl an z.B. Story Points, die Sie in der Zeit erledigen können.

​Jetzt gehen Sie Ihr Backlog einfach von oben nach unten durch und addieren die Schätzungen. Irgendwann haben Sie den zuvor ausgerechneten Umfang erreicht und wissen, was Sie bis zu diesem Datum noch schaffen.

pencil box outline

​​Beispiel für die Release Planung mit zeitlicher Komponente

​Sie haben eine mittlere Velocity von 50 Punkten pro Sprint. Ihre Deadline liegt noch 10 Sprints in der Zukunft. Sie können damit 500 Punkte an Funktionalität liefern.

​Jetzt gehen Sie Ihr Backlog von oben nach unten durch und zählen die Schätzungen zusammen. Bei spätestens 500 Punkten sollten Sie sichh überlegen, ob diese Funktionalitäten noch erreicht werden können.

​Release nach Umfang

​Wenn der Umfang bereits feststeht, der unbedingt geliefert werden muss, dann können Sie ähnlich wie bei dem Umfang mit der Zeit, zunächst einmal Ihre Velocity ausrechnen. Dann wissen Sie, welchen Umfang Sie bereits benötigen. Ausgehend von diesen Daten sind Sie nun in der Lage den Umfang durch die Velocity pro Sprint zu teilen und dann wissen Sie, wie lange (Anzahl der Sprints) Sie für den Umfang benötigen.

pencil box outline

​​Beispiel für die Release Planung mit Umfang

​Sie haben einen Backlog mit einem geschätzen Umfang von 500 Punkten. Ihr mittlere Velocity liegt bei 50 Punkten pro Sprint. ​Sie teilen die 500 Punkte durch 50 und wissen, dass Sie 10 Sprints dafür benötigen werden.

​Typische Grundursachen, wenn Sie Releases benötigen​

​In den letzten Jahren durfte ich ettliche Teams beobachten und ich finde es immer wieder interessant neue Tatsachen zu lernen. Ebenso ist es spannend, dass häufig immer gleiche oder ähnliche Grundursachen in den Teams und den Unternehmen stecken. Diese Grundursachen hinsichtlich der Release Planung in Scrum, schaue ich mir nun in den folgenden Abschnitt zum Abschluss noch einmal genauer an.

Die folgenden Punkte sind als kleine Impulse gedacht und nicht abschließend betrachtet. Nehmen Sie diese bitte als Gedankenanstoß.

​Team ist kein wirkliches Team

​Wenn Sie eine Release Planung brauchen, dann prüfen Sie doch einmal genau Ihr Teamsetting. Also ist das Team wirklich ein Team? Kann es sich eine Aufgabe aus dem Backlog nehmen und diese von Anfang bis Ende durchgehen bearbeiten?

​Aufgaben werden nicht fertig

​Schaffen Sie es zum Ende des Sprints wirklich ein Inkrement zu erstellen? Sind die Aufgaben für die Fertigstellung gedacht?

​Falscher Teamschnitt

​Wenn Sie Featureteams besitzen und mit diesen wirklich das Backlog abarbeiten, dann haben Sie eine gute Ausgangsbasis. Häufig finden sich Strukturen in Teams, die genau das nicht erlauben. Hier finden viele Übergaben, und weitere Verschwendungsarten, innerhalb des Teams statt.

Nicht selten werden Teams um das doppelte schneller, nur weil die jetzt zusammensitzen und eben genau das früher nicht getan haben. Es benötigt nicht unbedingt viel, aber das richtige Team mit den richtigen Leute am gleichen Platz ist auch für die Release Planung in Scrum sehr wichtig.

Sebastian

Ein paar Worte über den Autor
Agile Team Facilitator Sebastian Schneider
Agile Team Facilitator Sebastian Schneider
Sebastian Schneider CSP
Sebastian Schneider CSP-PO

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Sei auch mit dabei: Der Newsletter zu Scrum aus Augsburg.

__CONFIG_colors_palette__{"active_palette":0,"config":{"colors":{"62516":{"name":"Main Accent","parent":-1}},"gradients":[]},"palettes":[{"name":"Default Palette","value":{"colors":{"62516":{"val":"var(--tcb-skin-color-0)"}},"gradients":[]}}]}__CONFIG_colors_palette__
Hier gehts lang!
>