Mut zur Wahrheit: Der erste Releaseplan

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!

Geschrieben von

bgloger-redakteur bgloger-redakteur

TEILE DIESEN BEITRAG

3 Antworten zu “Mut zur Wahrheit: Der erste Releaseplan”

  1. Hans-Peter Korn sagt:

    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/

    • Karl sagt:

      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.

  2. H.-P Korn sagt:

    Interessant, dass mein Kommentar bis heute nicht freigeschaltet wurde …. was das zu viel “Mut zur Wahrheit” ??

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.