Kostenschätzung und Zeitplan für ein agiles Projekt?

„Wir möchten Thema X umsetzen. Könnt ihr uns eine Größenordnung für die Kosten und einen groben Fertigstellungstermin nennen?“ Diese Frage steht regelmäßig am Beginn eines Projekts oder Releases mit einem Zeithorizont von ca. drei bis sechs Monaten.

Planung ersetzt den Zufall durch Irrtum

In einem agilen Vorgehen ist der Scope zu Beginn – wenn überhaupt – nur unzureichend bekannt und ändert sich mit der Zeit laufend. Welchen Sinn hat in diesem Kontext eine Planung für ein bis zwei Quartale? In den meisten Fällen soll in diesem Zeitraum ein größeres Business-Ziel erreicht werden: die Einführung von eBooks auf einer Plattform, ein völlig neuer Vertriebskanal, eine neue App-Plattform, die Einführung eines Features, das sich durch die gesamte Software-Plattform zieht. Für dieses große Ziel möchten wir einen groben Weg abstecken bzw. einen Plan haben, wie wir es erreichen können.

Aber wie verträgt sich eine solch „langfristige“ Planung mit den Ideen des agilen Manifests? Der agile Grundsatz „auf Änderungen zu reagieren ist wichtiger, als einen Plan zu verfolgen” bedeutet nicht, keinen Plan zu haben. Stellt das Produktteam während der Entwicklung fest, dass bestimmte Aspekte oder Features wichtiger/unwichtiger bzw. aufwändiger/einfacher sind als gedacht, wird der bisherige Plan geändert – eine bewusste Entscheidung. Keinen Plan für die Erreichung des Ziels zu haben, läuft in der Regel auf eine Art „Sichtflug“ hinaus und das große Ziel gerät schnell aus den Augen. Stattdessen erstellen wir eine grobe Planung, die wir jederzeit anpassen können.

Diese Planung ist aber nicht nur für das Produktteam, sondern auch für die übrigen Stakeholder einer Produktentwicklung (Management, Marketing & Co) wichtig. Aus dieser Richtung wird meist die eingangs formulierte Frage nach Aufwand und Dauer für die eigene Planung gestellt:

• Für das Vorhaben muss Budget organisiert werden. Dafür ist ein geschätzer Kostenrahmen nötig. Es ist nicht wichtig, dass wir auf den Cent genau den Aufwand ermitteln. Es ist vollkommen ausreichend, einen Rahmen (mit etwas Puffer) für die Budgetierung abzuschätzen.
• Damit das neue Feature oder Thema beworben oder am Markt angekündigt werden kann, ist wichtig, einen ungefähren Go-Live-Termin festzulegen. Auch hier ist es nicht zwingend erforderlich, auf den Tag genau einen Fertigstellungstermin für die Produktentwicklung zu nennen, sondern einen Meilenstein wie „zum Ende des 3. Quartals“. Damit kann der Go-Live am Markt in diesem Fall noch vor dem Weihnachtsgeschäft erfolgen. Wir möchten also eine Planung erstellen, die basierend auf unserem heutigen Wissen den Weg zu unserem Ziel darstellt und uns eine grobe Prognose für die Zukunft erlaubt.

Der Weg zum Ziel – grobe Planung mit wenig Aufwand

Die Planung entsteht ähnlich wie die Planung für eine Reise: Welche Stationen müssen wir zurücklegen, um unser Ziel zu erreichen? In unserem Fall handelt es sich bei der Reiseplanung um ein Product Backlog. Die einzelnen „Stationen“ sind grobe Backlog Items. Um zu diesem initialen Backlog zu kommen, gibt es mehrere Herangehensweisen. Welche die „richtige“ ist, hängt davon ab, wie das Ziel definiert ist:

• Geschäftsziel: Hat das Produktteam ein Geschäftsziel – wie bspw. „Wir möchten in unserem mobilen Vertriebskanal in den nächsten zwölf Monaten 25% mehr Umsatz generieren“ – verfeinert es dieses Ziel mit Techniken wie Impact Mapping und füllt das Backlog mit den ermittelten Deliverables.
• Prozess: Besteht das Ziel aus der Umsetzung eines bekannten Prozesses – wie bspw. eines Online Shops – lassen sich grobe Epics anhand der einzelnen Prozessschritte ableiten und gruppieren: „Welche Schritte unternimmt der Kunde zum Finden von Artikeln, zum Hinzufügen zum Warenkorb und zur endgültigen Bestellung?„. Dabei sammelt das Produktteam alle Aspekte, die ihm für die Planung wichtig erscheinen – weil sie besonders wichtig für die Erreichung des Ziels oder wahrscheinlich besonders knifflig in der Umsetzung sind.
• Anforderungsliste: Liegt eine Anforderungsliste vor, ist es meist sinnvoll, dass das Produktteam die Anforderungen anhand eines Prozesses (s.o.) oder eines ähnlichen Konzepts strukturiert und groben Blöcken zuweist. Das weitere Vorgehen ist dann analog zu dem prozessbasierten.

Unabhängig welche der drei beschriebenen Wege benutzt wird, um das Backlog zu füllen, sollte es vom gesamten Produktteam im Rahmen eines Workshops erarbeitet werden – nicht von Einzelpersonen. Die einzelnen Backlog Items werden später beschätzt. In den Diskussionen während des Workshops kommen viele wichtige Informationen zur Sprache, die Einfluss auf die Schätzung haben. Aus diesem Grund ist es hilfreich, wenn diese Informationen direkt als Notizen an den Backlog Items vermerkt werden. Die Notizen und das Backlog erheben aber keinen Anspruch auf Vollständigkeit aller Details. Kommen später Informationen hinzu, wird die Planung geändert.

Initiales Backlog beschätzen

Als nächstes werden die Backlog Items mit einer Schätzung versehen. In einem agilen Team liegt es nahe, diese Schätzung in Form von Story Points durchzuführen. Die Erfahrung zeigt aber, dass Story Points für eine Schätzung mit dieser „Flughöhe“ zu feingranular sind. Ich rate deshalb dazu, eine andere Schätzgröße zu verwenden, die zunächst nicht mit Story Points in Verbindung steht:

• T-Shirt-Größen: Das Team verwendet T-Shirt-Größen, um die Komplexität der Backlog Items einzuordnen. Ich empfehle, maximal XS, S, M, L, XL zu verwenden. Im Grunde reichen drei Basisgrößen. Weitere Größen führen zu einer Scheingenauigkeit und machen die Schätzung deutlich aufwändiger.
• Aufwandspunkte: Aufwandspunkte verhalten sich wie Story Points auf einer höheren Flughöhe. Dafür haben sich die ersten Zahlen der Fibonacci-Folge eingebürgert (1, 2, 3, 5, 8, 13, …). Auch hier reichen erfahrungsgemäß die ersten drei bis vier Größen aus. Kann das Team ein Backlog Item nicht beschätzen, sollte es in kleinere Items zerlegt oder der Inhalt durch Annahmen so abgegrenzt werden, dass es sich beschätzen lässt. Wir haben gute Erfahrung damit gemacht, die Backlog Items in diesem Fall mit Hilfe von Dimensional Planning in verschiedene Ausbaustufen zu zerlegen.

Am Ende des Planungs- und Schätz-Workshops liegt ein erstes Product Backlog vor, das aus beschätzten Items besteht. Im Idealfall wurde das Backlog auch bereits priorisiert, so dass die Items weiter „unten“ nur oberflächlich besprochen und beschätzt werden müssen.

Ein solches Backlog enthält eine Größenordnung von drei bis vier Dutzend Items. Durch ein entsprechendes Schätzverfahren lässt sich die Ermittlung der Schätzungen beschleunigen – das Team ordnet die Items visuell Aufwandskategorien zu. Befinden sich mehr Einträge im Backlog könnte die Flughöhe zu niedrig sein.

Vom Backlog zu Planung

Um aus dem beschätzten Backlog eine Planung abzuleiten, benötigen wir zwei bis drei Erfahrungswerte aus der bisherigen Arbeit des Produktteams. Die Teammitglieder suchen sich Features, Prozesses oder Module, die sie bereits erfolgreich umgesetzt haben und ordnen sie in dasselbe Raster ein wie die neuen Backlog Items.

1. Da für diese Items die tatsächlichen Story Points bekannt sind, kann ein grobes Mapping von Aufwandspunkten (AP) auf Story Points definiert werden (Beispiel: 3 AP entsprechen 24 Story Points).
2. Anhand der durchschnittlichen Velocity des Teams lässt sich prognostizieren, wie lange die Umsetzung ungefähr dauern wird (durchschnittliche Velocity 24 Story Points => für ein Backlog Item mit 3 AP benötigt das Produktteam ca. einen Sprint). In Abhängigkeit von der Sprint-Dauer lassen sich jetzt für die einzelnen Items des Backlogs Termine ableiten. Diese Vorhersage ist für die nächsten ein bis zwei Sprints noch relativ genau. Je weiter die Prognose in die Zukunft reicht, desto ungenauer wird sie. Ähnlich wie eine Wettervorhersage: Das Wetter der nächsten paar Tage lässt sich relativ genau vorhersagen, für in drei Monaten nur sehr ungenau.
3. Für den Budgetrahmen ist es wichtig, die Kosten eines Sprints zu kennen (bspw. Kosten für die Entwickler, die Infrastruktur etc.). Basierend auf der Planung aus Schritt 2 lässt sich ermitteln, wie viele Sprints für „alle“ Backlog Items benötigt werden. Multipliziert mit den Kosten eines Sprints, ergibt sich der prognostizierte Budgetrahmen. Mit Hilfe dieser beiden Schritte lässt sich eine intiale Aussage über den Zeit- und Budgetrahmen der Produktentwicklung treffen.

Wasserlinie und Burn Up – kontinuierliche Planung

Während der Entwicklung werden diese beiden Planungsgrößen laufend aktualisiert. Die Terminplanung durch ein Burn-Up-Diagramm und die Budgetplanung durch eine „Wasserlinie“ im Backlog.

Burn-Up-Diagramm

Im Gegensatz zu einem Burn-Down- ist beim Burn-Up-Diagramm der zu erledigende Scope nicht fixiert und eignet sich damit für die langfristige Planung besser. In der folgenden Abbildung ist ein beispielhaftes Diagramm zu sehen.

Sobald die untere Linie der kumulierten erledigten Arbeit die Scope-Linie erreicht, ist der gesamte Scope umgesetzt. Durch ein Verlängern der Linie in die Zukunft lässt sich dieser Zeitpunkt prognostizieren und erlaubt eine kontinuierliche, transparente Darstellung, ob der usprünglich ermittelte Termin noch haltbar ist. Insbesondere wird ersichtlich, welche Auswirkungen Scope-Änderungen auf den Termin haben.

Backlog mit Wasserlinie

Die Wasserlinie im Backlog beruht auf den Kosten eines Sprints und stellt den Punkt da, bis zu dem „noch Geld da ist“. Backlog Items oberhalb diese Linie können mit dem aktuellen Budget noch umgesetzt werden, Elemente darunter nicht. Am Anfang steht diese Wasserlinie unterhalb aller bisher bekannten Elemente (siehe Abbildung unten). Werden zusätzliche Elemente bei gleichbleibendem Budget hinzugefügt, wandert die Linie nach oben.

Was passiert, wenn die Umsetzung der einzelnen Backlog Items mit höherem oder niedrigerem Aufwand geschieht, als ursprünglich geplant? Die Wasserlinie wird regelmäßig (z.B. nach jedem Sprint) mit dem aktuellen Budgetverbrauch aktualisiert:

• In der ursprünglichen Planung waren wir basierend auf einer mittleren Velocity davon ausgegangen, dass das Produktteam in einem Sprint ungefähr 3 AP umsetzen kann. Bei 19 AP ergeben sich mindestens sieben Sprints. Das Budget wurde für acht Sprints kalkuliert.
• Nach dem Ende des ersten Sprints ist nur das erste Backlog Item umgesetzt. Die verbleibenden 17 AP erfordern mindestens sechs Sprints zur Umsetzung, was noch innerhalb des Budgets ist. Die Wasserlinie bleibt unterhalb des letzten Backlog Items.
• Aufgrund technischer Probleme während der Entwicklung sind nach dem zweiten Sprint die ersten zwei Backlog Items umgesetzt. Mit der aktuellen mittleren Velocity (gleitender Dreierschnitt: (3 + 2 + 1) / 3 = 2 AP) werden für die verbleibenden 16 AP also noch mindestens acht Sprints benötigt, was nicht mehr im ursprünglichen Budget liegt. Die Wasserlinie wandert nach oben.

Es gibt Situationen, in denen die Sprints nicht „gleich teuer“ sind. Fehlt beispielsweise ein Freiberufler krankheitsbedingt einen ganzen Sprint lang, wird das Team wahrscheinlich wenige Scope umsetzen, es fallen während dieser Zeit aber auch geringere Kosten an. In Situationen mit ungleich teueren Sprints, rate ich die Wasserlinie aufgrund der tatsächlichen Sprint-Kosten anzupassen.

Fazit

Auch für agile Vorhaben lohnt sich eine Planung, die die nächsten ein bis zwei Quartale abdeckt. Diese Planung ist im agilen Sinne „good enough“, um grobe Prognose zu Zeit und Budget zu geben. „Good enough“ heißt, dass sie sich mit möglichst wenig Aufwand erstellen und anpassen lässt („minimize waste“). Sie gibt eine grobe Orientierung für die Erreichung eines Produkt- oder Projektziels. Wichtig ist eine solche Planung oft für die Termin- und Budgetplanung eines Vorhabens.

Während der Entwicklung wird die Terminprognose mit Hilfe eines Burn-Up-Diagramms laufend angepasst. Für die Budgetprognose wird eine Wasserlinie im Backlog verwendet.