Verlässliche, datenbasierte Prognosen statt Bauchgefühl. Genau dafür gibt es Forecasting-Methoden, die auf Empirie und Stochastik bauen.
Fragen wie „Wann ist es fertig?“ und „Wie lange dauert das?“ gehören in der Softwareentwicklung zum Alltag. Und reflexartig folgt die Antwort in Form einer subjektiven Schätzung, wenn es darum geht, Liefertermine vorherzusagen.
Doch die Realität zeigt: Schätzungen sind ungenau. Zudem verbrauchen sie wertvolle Zeit, die besser in die eigentliche Wertschöpfung investiert wäre. Das führt zu verpassten Fristen, Ressourcenengpässen und Frustration bei allen Beteiligten.
Doch was, wenn wir stattdessen die tatsächlich getane Arbeit unserer Teams als Grundlage nutzen könnten? Und genau hier kommen Forecasting-Methoden ins Spiel, die auf realen Daten basieren und damit eine zuverlässigere Planungsgrundlage bieten.
Der Cycle Time Scatterplot und Monte-Carlo-Simulationen bieten realistische Wahrscheinlichkeiten und Bereiche für verschiedene Szenarien: Wann ist ein einzelnes Feature fertig? Wann können wir mit einer bestimmten Anzahl von Features rechnen? Wie viele Items schaffen wir in einem definierten Zeitraum?
Die oft beobachtete Reflexreaktion auf diese Fragen ist ein „Das schätzen wir!“ Doch Schätzungen haben ihre Probleme, die im folgenden Abschnitt behandelt werden.
Inhaltsverzeichnis
Das Problem mit Schätzungen
Wo Schätzungen Sinn haben
Auch wenn Schätzungen Probleme verursachen, gibt es Gründe, die ihre Nutzung rechtfertigen.
Es gibt keine historischen Daten. Um gleich mal das Offensichtliche anzusprechen: Gibt es (noch) keine Daten aus der Vergangenheit, hat kein Forecasting-Verfahren Sinn. An dieser Stelle führt zum Start kein Weg an einer Schätzung vorbei. Und diese kann dann im späteren Verlauf ersetzt oder ergänzt werden, sobald genug Daten gesammelt wurden.
Schätzungen werden als Diskussions-Starter genutzt. Es kann gewünscht und von Vorteil sein, wenn Schätzungen genutzt werden, um alle Beteiligten ins Gespräch zu bekommen. Das ist v.a. bei vergleichenden Schätzungen interessant. Woher kommen im Team z. B. die unterschiedlichen Ansichten, die verschiedenen Schätzungen, das fehlende Wissen? Was wurde übersehen? Was anders verstanden?
Es stehen zu Beginn eines Vorhabens Go-/ No-Go-Entscheidungen an. Hier verhält es sich ähnlich wie beim oben beschriebenen Punkt zum Datenmangel: ohne vernünftige Grundlage funktioniert keine Vorhersage. Somit kann eine Schätzung des erwarteten Aufwands unumgänglich sein. Natürlich vor dem Hintergrund, dass eine solche Schätzung zumindest für neuartige Vorhaben nur sehr ungenau sein kann. Und einer entsprechenden Entscheidung steht neben den Kosten auch der erwartete Nutzen oder der zu erwirtschaftende Wert gegenüber.
Schätzungen helfen bei der Priorisierung und Sortierung. Dies kann als Variante des direkt vorher behandelten Punktes zu Go-/ No-Go-Entscheidungen verstanden werden. Bei einer wertorientierten Priorisierung sind Schätzungen nötig, wenn keine exakten Zahlen verfügbar sind.
Diesen guten Gründen steht jedoch die harte Realität beim Einsatz von Schätzungen gegenüber.
Die Realität bei der Nutzung von Schätzungen
Die unreflektierte und reflexartige Nutzung von Schätzungen in der Realität kann durch einige erste, einfache Fragen beleuchtet werden.
Wie wird geschätzt? Erfolgt die Schätzung vielleicht zwischen Tür und Angel? Und ist dann genau eine Zahl, die eben so aus der Hüfte geschossen wird? Oder tatsächlich mindestens eine Dreipunktschätzung? Was wird denn überhaupt geschätzt? Zeit oder Aufwand? Ist allen Beteiligten der Unterschied bewusst? Auf welcher Skala wird geschätzt? Wird über den Unterschied von 2,5 oder 3,2 Tagen diskutiert oder kommt eine Skala zum Einsatz, die Unsicherheiten, Unbekanntes und Risiken in Betracht zieht?
Wer schätzt? Oder anders gefragt: wie weit ist der schätzende Mensch von der eigentlichen Umsetzung entfernt? Schätzt der Vertrieb, eine Führungskraft, eine fachfremde Rolle oder doch das Entwicklungsteam? Wie viele Schätzende werden gefragt? Eine Person, mehrere Experten, das Umsetzungsteam?
Wie oft wird geschätzt? Ich habe schon Teams erlebt, die sich für den Unterschied zwischen Realität und Schätzungen rechtfertigen mussten. Für Schätzungen, die vor Jahren gemacht wurden. Von Menschen, die nicht an der Umsetzung beteiligt waren. Wie sieht es stattdessen aus mit einer rollenden Planung? Wird der Plan nachgebessert? Erfolgen regelmäßige Nachschätzungen, sobald neues Wissen generiert oder neue Einsichten gewonnen wurden?
Wie wahrscheinlich ist es, dass die Schätzung eingehalten wird? Oder anders ausgedrückt: wie realistisch ist der Plan? Ein guter Forecast bietet eine Wahrscheinlichkeit und eine gewisse Spannweite. Eine Schätzung kann so etwas selten bieten. Somit besteht die große und sehr reale Gefahr, dass Schätzungen als Lieferversprechen verstanden werden. Manchmal wird dann zu der Schätzung noch eine Konfidenz abgeben. Die wiederum selbst geschätzt wurde …
Und das alles führt zu einem Teufelskreis. Menschen stecken Zeit in hoffentlich möglichst genaue Schätzungen. Hinterher stellt sich heraus, dass diese Schätzungen falsch sind. Das ist kein Wunder, denn Schätzungen sind quasi definitionsgemäß immer falsch. Die oft beobachtete Reaktion darauf: „Wir müssen unbedingt besser schätzen!“ Also wird wertvolle Zeit investiert, um vermeintlich genauere Schätzungssysteme zu entwickeln. Und dann beginnt der Zyklus der Verschwendung wieder von vorne.
Was dabei vollkommen auf der Strecke bleibt, ist wirklich wertschöpfende Arbeit zum Nutzen der Kundin.
Und die erste Alternative bietet Prognosen für einzelne Arbeitselemente.
Forecasting für ein einzelnes Item: Der Cycle Time Scatterplot
Es ist diese Art von Frage an der Kaffeemaschine oder zwischen Tür und Angel: „Ich habe hier ein neues Item. Kannst Du mir kurz sagen, wie schnell das fertig sein kann?“ Und dafür gibt es einen einfachen Weg.
Zunächst eine wichtige Definition: Die Cycle Time ist die Zeit, die ein Arbeitselement „in Bearbeitung“ verbringt. Also die Zeit vom Start der Arbeit an diesem Element, bis zu dem Zeitpunkt, an dem es für das betrachtete System als „fertig“ gilt.
Und der beste Weg, einen Cycle Time Scatterplot zu verstehen, ist es, einen zu zeigen und zu beschreiben:
Die horizontale Achse zeigt das Datum, an dem ein bestimmtes Element abgeschlossen wurde.
Die vertikale Achse zeigt die Cycle Time für ein bestimmtes Element.
Somit zeigt der Cycle Time Scatterplot eine Übersicht, wann ein Element „fertig“ wurde und wie hoch seine Cycle Time war. (Randnotiz: Die verschiedenen Farben der Punkte im gezeigten Beispiel zeigen verschiedene Typen von Elementen.)
Für das Forecasting interessant sind die Lagemaße dieser Daten. Genauer: die verschiedenen Perzentile. So zeigt das 50%-Perzentil (der Median) an, dass eine Hälfte der Elemente kleiner ist und eine Hälfte größer. Auch hier wieder genauer formuliert und am Beispiel des gezeigten Diagramms: 50 % der Elemente haben eine Cycle Time von weniger als 2,72 Tagen. 50 % der Elemente haben eine Cycle Time von mehr als 2,72 Tagen.
Als weiteres Beispiel soll das 85%-Perzentil dienen. Im gezeigten Beispiel sagt dieses aus, dass 85 % der Elemente eine Cycle Time von weniger als 11,1 Tagen haben. Die verbleibenden 15 % der Elemente haben eine Cycle Time von mehr als 11,1 Tagen.
Und jetzt der spannende Punkt: genau diese Perzentile können als Forecasts für einzelne Elemente genutzt werden!
Anders formuliert kann z. B. das 85%-Perzentil so lauten: auf Basis der vergangenen Leistung des Teams wird ein neues Item mit einer Wahrscheinlichkeit von 85 % in 11,1 Tagen oder früher fertig.
Damit liefert uns der Cycle Time Scatterplot die Möglichkeit für echte Forecasts mit einer Wahrscheinlichkeit (x%) und einer Spannweite (Zeit y oder früher).
Nun haben wir ein Tool für die Prognose für einzelne Items. Doch weit häufiger benötigen wir Antworten für einen Arbeitsvorrat.
Forecasting für mehrere Items: Wann ist es fertig?
Monte-Carlo-Simulation für die Frage „Wann?“
Monte-Carlo-Simulationen sind am einfachsten anhand eines konkreten Beispiels erklärt. Nehmen wir an, unser Team hatte in den letzten sechs Iterationen die folgenden Throughputs:
| Iteration | Throughput |
|---|---|
| 1 | 5 |
| 2 | 4 |
| 3 | 7 |
| 4 | 9 |
| 5 | 3 |
| 6 | 8 |
Für dieses Beispiel legen wir fest, dass eine Iteration eine Woche lang ist. Die Länge könnte genauso gut zwei Wochen sein, ein Monat oder ein Quartal. Wichtig ist nur, dass die Länge bei allen Daten und Berechnungen gleich sein muss.
Aus diesen historischen Daten erzeugen wir nun ein mögliches zukünftiges Szenario, indem wir zufällige Werte aus der Vergangenheit wählen.
Nehmen wir an, wir wollen wissen: „Wann sind 30 Items fertig?“ Dazu wählen wir zufällig eine erste vergangene Iteration aus und da wir in diesem Beispiel sechs Iterationen zur Auswahl haben, könnten wir dazu buchstäblich einen sechsseitigen Würfel nutzen. Im ersten Wurf ermitteln wir die vergangene Iteration 5 mit einem Throughput von 3. Somit hat unsere erste simulierte zukünftige Iteration ebendiesen Throughput von 3. Dies wiederholen wir so lange, bis wir in Summe auf mindestens 30 Items kommen. In unserem Beispiel ist dies nach 6 Iterationen der Fall:
Somit ist die Antwort in dieser ersten Simulation: „30 Items sind nach 6 Iterationen fertig.“ Allerdings ist nur ein einzelner Durchlauf etwas dünn in seiner Aussagekraft.
Da wir uns das Gesetz der großen Zahlen zu Nutzen machen wollen, führen wir diese Simulation deshalb nicht einmal durch, sondern mehrere tausendmal.
Und alle Ergebnisse dieser x-tausend Simulationen sammeln wir in einem Histogramm zur weiteren Auswertung.
Histogramm und Auswertung für die Frage „Wann?“
Das Histogramm zur Auswertung der Monte-Carlo-Simulation sammelt alle Ergebnisse und zeigt diese wie folgt:
Die horizontale Achse zeigt das Ergebnis der jeweiligen Simulation. Bei der Frage „Wann sind 30 Items fertig?“ in unserem Beispiel also „Nach so vielen Iterationen haben wir mindestens 30 Items fertiggestellt“.
Die vertikale Achse zeigt die Anzahl der Simulationen, die zum gleichen Ergebnis kamen.
Und mit diesen Daten können wir nun fragen: „Mit welcher Wahrscheinlichkeit werden wir nach x Iterationen oder früher fertig?“
In unserem Beispiel haben wir 1.000 Simulationen durchgeführt. Wollen wir nun eine Wahrscheinlichkeit von z. B. 50 %, so müssen wir herausfinden, wann 50 % der Simulationen zum gewünschten Ergebnis kamen. Bei 1.000 Durchläufen sind das also 500 Simulationen.
Weil wir wissen wollen „nach x Iterationen oder früher“, zählen wir die vertikalen Balken des Histogramms von links auf, bis wir mindestens 500 Simulationen zusammen haben. In unserem Beispiel ist das bei Iteration 6.
Jetzt ist eine 50%-Wahrscheinlichkeit nicht besser als ein Münzwurf. Also wollen wir etwas mehr Sicherheit und gehen auf 85 %. Das Vorgehen ist wieder das gleiche: wir zählen von links die Anzahl der Simulationen auf, bis wir auf mindestens 850 (85 % von 1.000) kommen. In unserem Beispiel ist das bei Iteration 7 der Fall:
Damit haben wir die Antwort auf die Frage „Wann ist es fertig?“ Wir können in unserem Beispiel jetzt sagen: Mit einer Wahrscheinlichkeit von 85 % werden 30 Items nach 7 Iterationen oder früher fertig.
Somit liefert uns die Monte-Carlo-Simulation die Möglichkeit für echte Forecasts mit einer Wahrscheinlichkeit (x%) und einer Spannweite (Iteration n oder früher).
Und diese Antwort lässt sich noch besser darstellen.
Darstellung als kalendarische Übersicht
Ein kraftvolles Werkzeug zur Kommunikation werden die Ergebnisse der Monte-Carlo-Simulation, wenn sie mit Terminen versehen werden:
Im grünen Bereich ab 85 % sind wir in unserem Beispiel, wie im vorherigen Abschnitt bereits gezeigt, und können auf die Frage eines Stakeholders antworten: „Mit einer Wahrscheinlichkeit von 85 % werden 30 Items am 09.07. oder früher fertig.“
Würde dieser Stakeholder nun verlangen, dass wir bitte bereits am 25.06. fertig sein sollen, könnten wir antworten: „Können wir schon angehen, nur sehen wir dann lediglich eine Wahrscheinlichkeit von bestenfalls 35 %, dieses Ziel zu erreichen.“
Und damit können wir mit einer kalendarischen Übersicht ganz andere Diskussionen mit allen Beteiligten führen, als es mit einfachen Schätzergebnissen der Fall ist.
Bleibt noch eine letzte zu klärende Frage: Wie viele Items schaffen wir in einem definierten Zeitraum?
Forecasting für mehrere Items: Wie viel schaffen wir?
Monte-Carlo-Simulation für die Frage „Wie viel?“
Als Grundlagen nehmen wir wie beim Wann-Beispiel an, dass unser Team in den letzten sechs Iterationen die folgenden Throughputs erreichte:
| Iteration | Throughput |
|---|---|
| 1 | 5 |
| 2 | 4 |
| 3 | 7 |
| 4 | 9 |
| 5 | 3 |
| 6 | 8 |
Ebenso legen wir wieder fest, dass eine Iteration eine Woche lang ist und alle Daten und Berechnungen diese Iterationslänge beachten. Und aus diesen historischen Daten erzeugen wir wieder ein mögliches Zukunftsszenario, indem wir zufällige Werte aus der Vergangenheit nutzen.
Diesmal wollen wir wissen: „Wie viele Items schaffen wir in 6 Iterationen?“ Im ersten Wurf ermitteln wir die vergangene Iteration 4 mit einem Throughput von 9. Somit hat unsere erste simulierte zukünftige Iteration einen Throughput von 9. Dies wiederholen wir nun 6-mal (wir suchen ja die Antwort für genau 6 Iterationen) und kommen in der ersten Simulation auf 39 Items:
Damit ist die Antwort in dieser ersten Simulation: „Nach 6 Iterationen haben wir 39 Items fertig.“
Und wieder machen wir uns das Gesetz der großen Zahlen zu eigen und führen 1.000 Simulationen durch, deren Ergebnisse wir zur weiteren Auswertung in einem Histogramm sammeln.
Histogramm und Auswertung für die Frage „Wie viel?“
Das Histogramm zur Auswertung der Wie-viel-Monte-Carlo-Simulation zeigt dieses Bild:
Die horizontale Achse zeigt das Ergebnis der jeweiligen Simulation. Bei der Frage „Wie viele Items schaffen wir in 6 Iterationen?“ in unserem Beispiel steht hier also „Nach 6 Iterationen haben wir so viele Items fertiggestellt“.
Die vertikale Achse zeigt die Anzahl der Simulationen, die zum gleichen Ergebnis kamen.
Diesen Daten fragen wir nun: „Mit welcher Wahrscheinlichkeit schaffen wir in 6 Iterationen wie viele Items oder mehr?“
Für eine erste Betrachtung interessieren wir uns wieder für eine 50%-Wahrscheinlichkeit. Da wir wissen wollen „nach x Items oder mehr“, zählen wir die vertikalen Balken des Histogramms von rechts auf, bis wir mindestens 500 Simulationen zusammen haben. In unserem Beispiel trifft dies bei 34 Items zu. Für eine 85%-Wahrscheinlichkeit und entsprechend 850 Simulationen kommen wir bei 29 Items heraus:
Somit haben wir die Antwort, die wir mit „Wie viel schaffen wir?“ suchten und können in unserem Beispiel sagen: Mit einer Wahrscheinlichkeit von 85 % schaffen wir in 6 Iterationen 29 Items oder mehr.
Die Monte-Carlo-Simulation liefert also echte Forecasts mit einer Wahrscheinlichkeit (x%) und einer Spannweite (n Items oder mehr).
Und diese Antwort lässt sich ebenfalls noch besser aufbereiten.
Darstellung als Tabelle
Die verschiedenen Wahrscheinlichkeiten samt dazugehörigen Prognosen aus der Simulation sehen als Tabelle so aus:
Im grünen Bereich bei 85 % können wir auf die Beispielfrage antworten: „Mit einer Wahrscheinlichkeit von 85 % werden wir in 6 Iterationen 29 Items oder mehr schaffen.“
Würde ein Team nun, aus welchen Gründen auch immer, sagen, dass sie sich lieber ganze 37 Items vornehmen wollen, könnten wir antworten: „Das könnt ihr versuchen, nur sehe ich dann lediglich eine Wahrscheinlichkeit von 25 %, dieses Ziel zu erreichen.“
Und damit erlaubt diese Tabelle eine ganz andere Diskussionsqualität, als es reine Schätzwerte tun.
Die üblichen Einwände
Die drei vorgestellten Werkzeuge stoßen im echten Leben auf Missverständnisse, Unverständnis und Widerstände. Dieses Kapitel behandelt die zwei wichtigsten.
„Da fehlt doch die Ticketgröße und Abwesenheiten!“
Die am häufigsten gehörten Fragen bzw. Einwürfe drehen sich um diesen Themenkomplex:
- Funktioniert das nur, wenn ich alle Items gleich groß schneide?
- Muss ich dann verschiedene Item-Größen bei der Prognose trennen?
- Wie rechne ich da Abwesenheiten mit ein?
Die kurze Antwort: das ist alles unnötig.
Die etwas längere Antwort: das bilden die historischen Cycle Times und Throughputs bereits ab.
War in der Vergangenheit ein Item einfach zu erledigen und brauchte wenig Zeit? Oder war es zwar einfach, brauchte jedoch aufgrund von Wartezeiten länger? Oder war es ein komplexes Vorhaben und die Umsetzung dauerte entsprechend? Dann bildet das die Cycle Time dieser Items bereits ab. Und damit ist es Bestandteil der Auswertung des Cycle Time Scatterplot.
Waren die Entwicklerinnen und Entwickler im Urlaub oder auf einem Hackathon? War aufgrund von Krankheiten weniger „Entwicklungskraft“ vorhanden? Oder hat das Team an zu vielen Dingen gleichzeitig gearbeitet? Dann bildet dies der historische Throughput bereits ab und diese Umstände fließen in die Monte-Carlo-Simulation mit ein.
Sprich: Das vergangene Verhalten des betrachteten Systems beschreibt die tatsächliche Realität und Vielfalt bei der Softwareentwicklung bereits, wird bei den Prognosen mit berücksichtigt und muss nicht extra behandelt werden.
„Da rechne ich einfach mit dem Durchschnitt!“
Jetzt kann es natürlich sein, dass man sich diese ganze Arbeit sparen und einfach mit simplen Durchschnittswerten rechnen will. Dann machen wir das doch mal.
Für das Szenario „Wann ist ein Item fertig?“ kommen wir mit unseren Beispieldaten auf eine durchschnittliche Cycle Time von 6,3 Tagen. Werfen wir aus Neugier einen schnellen Blick auf unseren Cycle Time Scatterplot, entspricht das grob geschätzt einer Wahrscheinlichkeit von vielleicht 65 %.
Der durchschnittliche historische Throughput in unserem Beispiel liegt bei 6 pro Iteration. Ziehen wir dieses arithmetische Mittel bei der Beantwortung der Frage „Wann sind 30 Items fertig?“ zurate: 30 Items geteilt durch 6 Items pro Iteration ist gleich 5 Iterationen. Eine Gegenprüfung mit den Monte-Carlo-Ergebnissen zeigt uns hier eine Wahrscheinlichkeit von bestenfalls 35 %.
Zu guter Letzt noch „Wie viele Items schaffen wir in 6 Iterationen?“ Die Rechnung ist denkbar einfach: 6 Iterationen mal 6 Items pro Iteration ist gleich 36 Items. Und hier zeigt die Gegenprüfung eine Wahrscheinlichkeit von lediglich 30 %.
Klar kommt man mit Durchschnittswerten schnell und einfach zu einem Ergebnis. Allerdings erfüllt diese Berechnung nicht den Anspruch an eine gute Prognose, auch eine Wahrscheinlichkeit angeben zu können. Wir konnten dies in diesem Beispiel nur tun, da wir die Resultate des Cycle Time Scatterplot und der Monte-Carlo-Simulationen zur Verfügung hatten. Und diese zeigen für die Durchschnittsberechnungen sehr niedrige Wahrscheinlichkeiten.
Fazit
Der Cycle Time Scatterplot und Monte-Carlo-Simulationen basieren auf Empirie und Stochastik. Sie nutzen die getane Arbeit eines Teams als Grundlage und das tatsächliche Verhalten des Entwicklungsprozesses statt fiktiver Schätzwerte.
Die Ansätze liefern echte Prognosen (Forecasts) mit einer Wahrscheinlichkeit (Probability) und einer Spannweite (Range). Diese Kombination erlaubt Diskussionen und Risikobetrachtungen auf einer Ebene, die Schätzungen alleine nicht bieten.
Beide Methoden ergänzen bestehende Planungs- und Priorisierungsprozesse. Sind neue Prognosen nötig, so ist dies im Handumdrehen möglich. Es sind lediglich neue Zahlen für die Simulation nötig und die Ergebnisse liegen umgehend vor – ohne die Notwendigkeit, Ressourcen raubende Schätzmeetings einberufen zu müssen.
Und so entlastest Du mit den beiden Werkzeugen Dein Team, setzt realistische Erwartungen und erhöhst gleichzeitig die Planungssicherheit.
Schnapp Dir die 7 Fragen für hochproduktive Entwicklungsteams und buche Deine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Dich am wirkungsvollsten unterstützen kann.
