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!

Agile Toolbox
Scrum
Scrum Artefacts
Scrum-Begriffe
bgloger-redakteur
November 12, 2013

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen