Nicht vieles ist so schön wie das Gefühl, einen Plan zu haben. Das gilt sowohl für das Privatleben – beispielsweise für den lang ersehnten Urlaub – als auch für den Beruf, speziell in der Projektwelt. Doch was passiert, wenn der sorgsam geschmiedete Plan nicht den Hauch einer Chance auf eine halbwegs vernünftige Umsetzung hat? Das Hotelzimmer liegt nicht wie angekündigt direkt am Meer, sondern man schaut in den dunklen Innenhof, wo Bauarbeiter seit 7 Uhr mit einem Presslufthammer den Boden rausreißen und außerdem ist dem jüngsten Spross speiübel, die Tauchausflüge sind also gestrichen.
Beim Lieblingsprojekt des Vorstandes verhält sich das nicht anders: Werdende Mütter und Väter, die den Großteil des Entwicklungs-Know-hows auf sich vereinen, nehmen Elternzeit, noch bevor sie es geschafft haben, wenigstens einen Teil ihres Wissens mit den Kollegen zu teilen. Der nächstbeste Mitarbeiter wurde von der alljährlichen Grippewelle ereilt und natürlich kommt auch noch ein gesetzliches Muss-Thema reingeflattert, womit die restlichen Reserven fast vollends aufgebraucht wären. Und, hat damit jemand gerechnet, als man das Projekt vor etwas mehr als einem Jahr auf „naja, sagen wir mal 2000 Personentage“ geschätzt hat? In den meisten Fällen leider nicht. Die Leidtragenden sind in solchen Fällen meist die Übriggebliebenen, die nun die gleiche Arbeit mit der Hälfte der Ressourcen erledigen müssen – der Termin steht ja schließlich schon seit einer halben Ewigkeit fest, Verzögerungen werden mit Argwohn quittiert.
Doch wie kann man hier Abhilfe schaffen? Ist das Projekt zeitlich bereits so weit fortgeschritten wie oben beschrieben, bleibt den Teams nicht sehr viel mehr, als mit den gesammelten Informationen für Transparenz bezüglich der tatsächlich leistbaren Arbeit herzustellen und entweder auf Verständnis zu hoffen, oder eben zusätzliche Ressourcen zur Verfügung gestellt zu bekommen.
Diese Transparenz lässt sich besonders einfach mit Hilfe eines Releaseplans realisieren. Hierbei werden sämtliche User Stories der vergangenen Monate nach Bearbeitungszeit sortiert (diese lassen sich in elektronischen Tools wie JIRA relativ einfach bestimmen). Am Ende erhält man sowohl die kürzeste, als auch die längste Durchlaufzeit für eine User Story und kann mit großer Wahrscheinlichkeit sagen, dass keine der noch offenen User Stories länger dauern wird, als die bisher auf „done“ gesetzten Stories. Da man außerdem eine durchschnittliche Velocity pro Sprint erhält, kann man nun auch eine Aussage darüber treffen, wie viele Sprints das Entwicklungsteam für die noch offenen und bereits geschätzten Stories noch benötigen wird.
Da hier in der Regel eine deutliche Diskrepanz zwischen Planung und Realität zu Tage tritt, hat ein solcher Releaseplan erfahrungsgemäß mindestens zwei Konsequenzen: Er sorgt für eine noch deutlichere Priorisierung der offenen Projekte und User Stories. Und zweitens tritt der ebenfalls erwünschte Effekt ein, dass die Scrum Teams nun häufiger und früher in die Planung einbezogen werden, um böse Überraschungen zukünftig zu vermeiden.
Der Releaseplan ist also ein einfaches und wirkungsvolles Tool, um auf der Basis bisher gesammelter Erfahrungen und tatsächlich gemessener Velocity relativ valide Aussagen darüber treffen zu können, auf welcher Stufe sich mein Produkt gerade befindet. Probieren Sie es aus!
- Beratung
-
-
IM FOKUS
- Die 10 Top-Gründe für borisgloger Wir reden nicht nur, wir lösen jeden Tag Probleme bei unseren Kunden.
- Warum Sie mit uns remote genauso effektiv arbeiten können Wir gestalten virtuelle Zusammenarbeit als aktivierendes Erlebnis.
- Warum das Arbeitsmodell der Digitalisierung Agile heißt Die Digitalisierung verändert, wie wir arbeiten und wie wir Arbeit organisieren.
-
- EXPERTISE
Expertise
-
- METHODEN
Methoden
-
- BRANCHEN
Branchen
-
-
- Academy
-
-
IM FOKUS
- Lernen Sie von den agilen Praktiker:innen Zeit für neue Skills? Wir geben Ihnen die Instrumente aus dem agilen Werkzeugkasten an die Hand.
- Future Skills Conference by bg Die relevantesten Trends und Trainings zur Befähigung Ihrer Talente in der agilen Transformation – kompakt und digital vermittelt am 18.10.2023 von unseren Agilitätsexpert:innen.
- Werden Sie Agile Coach Steckt in Ihnen ein Agile Coach? Dann haben wir ein Angebot für Sie.
-
- TRAINING
Trainings
-
- COACHING
Coaching
-
- DIGITALES LERNEN
Digitales Lernen
-
-
- Über uns
-
-
-
- UNTERNEHMEN
Unternehmen
-
- PUBLIKATIONEN
Publikationen
-
- EVENTS
Events
-
-
- CSR
- Karriere
- Publikationen
- Kontakt
- AT
- DE
- EN
3 Antworten zu “Mut zur Wahrheit: Der erste Releaseplan”
Das:
“Da man außerdem eine durchschnittliche Velocity pro Sprint erhält, kann man nun auch eine Aussage darüber treffen, wie viele Sprints das Entwicklungsteam für die noch offenen und bereits geschätzten Stories noch benötigen wird.”
beruht ja darauf, dass ALLE zukünftigen Stories bereits vorhanden sind – beruht also auf dem “klassischen” Big Design Up Front (BDUF) im Gegensatz zum “agilen” Just Eonough Design Up Fronf (JEDUF). Letzterer ist gekennzeichnet dadurch, dass es für die zukünftige Entwicklungsarbeit an einem Produkt mit einem Horizont von mehr als 6 bis 9 Monaten zunächst mal grobe “Epics” bezüglich Business-Funktionen und Architektur gibt. Daraus werden dann für die in den nächsten bis zu 6 bis 9 Monate anstehenden Releases “Features” abgeleitet. Diese bilden die Basis für die Prognose (nicht verbindlichen Planung!!!) der nächsten 3 bis 4 Releases. Erst im Release Planning der anstehenden Releases werden aus den Features dieses anstehenden Releases die Stories abgeleitet. Und zwar von den daran arbeitenden TEAMS und nicht nicht nur vom jeweiligen PO.
DAS erst ist für mich “agil”.
Mehr dazu hier: http://scaledagileframework.com/release-planning/
Hallo, vielen Dank für das Feedback! Es wurde übrigens nicht absichtlich geblockt – wir mussten erst die Einstellungen für die Antworten ändern, so dass auch Links eingefügt werden können.
Interessant, dass mein Kommentar bis heute nicht freigeschaltet wurde …. was das zu viel “Mut zur Wahrheit” ??