Prognostizieren in agilen Projekten mit Monte-Carlo-Simulationen

Eine der häufigsten Fragen in Projekten ist: „Wann ist es fertig?“

Wann kommt das Feature, wann kommt das Release? Oder auch: Wie viele Features können wir bis zu einem bestimmten Datum umsetzen?

Eine Methode, mit der man Antworten finden kann, sind sogenannte Monte-Carlo-Simulationen. Dabei handelt es sich um eine Prognosemethode für komplexe Sachverhalte, die mit dem Aufkommen agiler Arbeitsweisen verstärkt in den Fokus geraten ist.[1] Tatsächlich sind Monte-Carlo-Simulationen aber keine agile Erfindung, sondern schon längst Teil des klassischen Projektmanagements und daher auch im Project Management Body of Knowledge zu finden.[2]

Im Folgenden möchte ich zeigen, wie man bereits einfache Monte-Carlo-Simulationen in Entwicklungsprojekten einsetzen kann. Wie man Simulationen wie die unten gezeigte mit wenigen Klicks in Microsoft Excel erstellt, habe ich hier beschrieben.[3]

Monte-Carlo-Simulationen: bei unsicheren Variablen prognostizieren

Monte-Carlo-Simulationen eignen sich für viele Wiederholungen von Experimenten mit unsicheren Variablen.

Vereinfacht gesagt geht es darum, Antworten auf Fragestellungen mit unsicheren Faktoren zu bekommen, in dem man sehr viele Experimente durchführt und die Häufigkeit der verschiedenen Ergebnisse betrachtet. Daraus liest man die Wahrscheinlichkeit ab, mit der diese Ergebnisse eintreten.

Ein Beispiel: Ich möchte wissen, welche Summe die wahrscheinlichste ist, wenn ich mit zwei sechsseitigen Würfeln würfle. Dafür würfle ich jetzt 1000 Mal und betrachte die Häufigkeit der jeweiligen Ergebnisse. So kann ich sehen, welche Gewinnchance ich habe, wenn ich beim nächsten Wurf 100€ auf 7 setze.[4]

Doch Vorsicht! Genauso, wie eine Simulation mit zwei Würfeln keine Aussagekraft hat, wenn ich vorhabe, mit drei Würfeln zu spielen, so kann ich mit den Daten eines fünfköpfigen Teams, das in einer Fläche zusammenarbeitet, nicht prognostizieren, was ein 20-köpfiges, verteiltes Team vermutlich leisten wird. Ich brauche also einen hinreichend stabilen Projektkontext.

Hier helfen agile Frameworks durch ihren iterativen Charakter enorm.

Scrum beispielsweise schreibt nicht nur stabile Teams vor, sondern auch gleichbleibende organisatorische Rahmenbedingungen, wie gleichbleibende Sprintlängen. Zudem stehen am Ende jedes Sprints fertig entwickelte Funktionalitäten und nicht nur Teilkomponenten. Ebenfalls hilfreich ist, dass Features in agilen Projekten üblicherweise in kleine Teile von ähnlicher Komplexität und Größe zerlegt werden, wie es etwa beim Slicing von User Stories geschieht. Hier haben sich als Zielmarke mittlerweile Umsetzungszeiten von ein bis zwei Tagen pro User Story etabliert. Eine exakt gleiche Größe ist natürlich nicht realistisch; aber da sich kleinere Unterschiede ausmitteln, ist sie auch nicht notwendig. Durch ihre Stabilität werden Sprints also vergleichbar und ihre wertstiftenden, vergleichbaren Ergebnisse können gut für Prognosen verwendet werden.

Features für 10 Sprints simulieren

Nehmen wir also an, wir haben ein Scrumteam. Das Team ist seit fünf Sprints eingespielt und die Teamzusammensetzung ist unverändert. Außerdem besteht im Team Klarheit darüber, was als ‚Feature‘ verstanden wird. Der Product Owner möchte nun wissen, wie viele Features das Team in den nächsten zehn Sprints liefern kann, damit er sein Backlog ordnen kann.

Dazu schaut er sich die Leistungen der letzten fünf Sprints an:

Sprint	Gelieferte Features
1	5
2	7
3	8
4	7
5	7

Er sieht, dass in drei von fünf Sprints sieben Features geliefert werden konnten und in je einem Sprint fünf beziehungsweise acht Features. Er geht nun davon aus, dass das für die nächsten Sprints so ähnlich bleiben wird und schließt daraus, dass in den nächsten Sprints mit 60-prozentiger Wahrscheinlichkeit wieder sieben Features geliefert werden, mit 20 Prozent Wahrscheinlichkeit fünf Features, und mit 20 Prozent acht Features.

Ihm ist übrigens auch klar, dass es sich hier um eine Momentaufnahme handelt und er mit neuer Datenlage neu prognostizieren wird.

Basierend auf diesen Wahrscheinlichkeiten simuliert der Product Owner nun 1000 Mal den Projektverlauf und bekommt folgendes Histogramm. 

Auf der x-Achse steht die Zahl der jeweils nach 10 Sprints erreichten Features, die y-Achse nennt die Häufigkeit des auf der x-Achse angezeigten Ergebnisses. Die Zahl über den Balken zeigt, wie oft das entsprechende Ergebnis in den 1000 Simulationen erreicht wurde.

Der PO sieht zunächst einmal, was er aufgrund seiner Datenlage ohnehin erwartet hatte: eine asymmetrische Verteilung. Er sieht außerdem, dass die meisten Simulationen 68 und 69 Features erreichten. Davon ging er aus, denn 68 Features hätte in diesem Fall bereits die Berechnung mit dem Durchschnitt ergeben. Interessanter ist aber, wie häufig andere Ergebnisse sind. Daran sieht er nämlich sofort, dass auch 59 Features noch im Bereich des Möglichen liegen, genau wie 76 Features.

Anders ausgedrückt: Basierend auf diesen Daten kann er mindestens 59 Features mit absoluter Sicherheit erwarten, 65 Features sind aber auch noch sehr wahrscheinlich. 76 Features sind hingegen möglich, aber sehr unwahrscheinlich, denn diese Zahl wurde in nur drei von 1000 Simulationen erreicht. Die Wahrscheinlichkeit, dass sein Team ihm 68 Features oder mehr liefern kann, liegt bei 50 Prozent – da könnte er auch eine Münze werfen! Unser PO überlegt sich nun, ob er nicht doch lieber kommuniziert, dass mit 90-prozentiger Wahrscheinlichkeit 63 bis 73 Features geliefert werden können.

Gutscheine für Features

Die Frage, wie sicher das Ergebnis eintritt, ist eine gute Basis für Diskussionen: Welche Sicherheit brauchen Product Owner oder Stakeholder? Reicht für ein Release zu einem Fixdatum eine Sicherheit von 85 Prozent? Oder müssen es 100 Prozent sein? Diese Betrachtung bietet die Möglichkeit, die sichtbaren Ergebnisse als Budgets verschiedenen Risikogrades zu betrachten und damit effektives Erwartungsmanagement betreiben zu können.

Als Scrum Master kommuniziere ich die simulierte, hundertprozentige Sicherheit gerne als Gutscheine und sage etwa dem Product Owner: „Das Entwicklungsteam kann dir zum gegenwärtigen Zeitpunkt 59 Gutscheine geben, die du bis zum Stichtag für Features einlösen kannst. Bei jedem Gutschein darüber hinaus steigt die Wahrscheinlichkeit, dass du ihn nicht einlösen können wirst.“

Wenn ihm die Zahl der hinreichend sicheren Gutscheine nicht reicht, muss man sich etwas überlegen. Häufig reicht eine verschlankende Neuordnung des Backlogs, manchmal kommt man um Ressourcenerhöhung oder Verschiebung einer Deadline nicht herum.

Vom Muss zum Kann

Die hier beschriebene Monte-Carlo-Simulation ist natürlich nur eine von vielen, aber die meiner Meinung nach nützlichste.[5] Sie legt den Fokus nämlich auf die Frage, was umgesetzt werden kann und weg von der Frage, was umgesetzt werden muss. Anders als die reine Durchschnittsprognose bietet die Monte-Carlo-Simulation also den Vorteil, dass sie Mögliches und Wahrscheinliches gleichermaßen darstellt. Für Stakeholder bedeutet das eine größere Projekttransparenz, für das Entwicklungsteam mehr Klarheit über die eigene Arbeit und für den Product Owner mehr Planungssicherheit. Genau dadurch ermöglichen regelmäßig – nach jeder Iteration – durchgeführte Monte-Carlo-Simulationen die effektive Steuerung von Projekten.

---

Über den Autor