Letztes Jahr habe ich zugesehen, wie ein CTO seinem Vorstand versprochen hat, dass ein Feature "bis Ende Q2" fertig sein würde. Ich war im Raum. Er hat sich das Datum aus den Fingern gesogen. Ich weiß das, weil ich seit zwei Wochen mit seinem Team gearbeitet hatte und es keine Chance gab — das Backlog hatte 140 Einträge, die Velocity des Teams war ein einziges Chaos, und zwei der fünf Entwickler gingen bald in Elternzeit. Q2 kam und ging. Das Feature wurde Mitte August ausgeliefert. Niemand war überrascht außer dem Vorstand.
Das passiert überall. In jeder Firma, mit der ich gearbeitet habe. Die Frage "wann ist es fertig?" hat mehr Vertrauen zwischen Engineering und Business zerstört als jeder Produktionsausfall es je könnte.
Und klar, ich verstehe das. Führungskräfte brauchen Termine. Verträge brauchen Termine. Marketing kann nicht ankündigen "irgendwann zwischen April und wer weiß wann." Aber die Lösung ist nicht, sich eine Zahl auszudenken und zu beten. Die Lösung ist, ehrlich zu sein über das, was man weiß und was nicht.
Deshalb habe ich einen Monte-Carlo-Lieferprognose-Simulator gebaut. Nicht weil die Welt noch ein agiles Tool brauchte — Gott weiß, es gibt genug davon — sondern weil ich immer wieder dasselbe Gespräch mit Engineering Managern hatte, die realistische Termine nennen wollten und keine Ahnung hatten, wie.
Die Zahl, die alles ruiniert hat
So läuft es normalerweise schief.
Der PM fragt: "wann ist das Backlog durch?" Der Lead denkt kurz nach, packt einen Puffer drauf weil er sich schon mal verbrannt hat, und sagt "acht Sprints." Der PM schreibt es auf. Erzählt es dem VP. Der VP erzählt es dem Kunden. Jetzt sind acht Sprints ein Versprechen. Nur dass es nie ein Versprechen war — es war das Bauchgefühl einer Person an einem Dienstagnachmittag nach zu viel Kaffee.
Und was bedeutet "acht Sprints" eigentlich? Der beste Fall? Der Durchschnitt? Das Szenario, in dem nichts schiefgeht und niemand krank wird und die API, von der man abhängt, sich nicht ändert und der Junior-Entwickler magisch über Nacht zum Senior wird? Wenn ich die Leute damit konfrontiere, sagen sie meistens sowas wie "naja, ich würde sagen, wir haben ganz gute Chancen." Super. Ganz gute Chancen. Schreib das in den Vertrag.
Daniel Kahneman nannte das den Planungsfehlschluss. Wir sind darauf programmiert, zu unterschätzen, wie lange Dinge dauern. Selbst wenn wir diesen Bias kennen, fallen wir trotzdem drauf rein. Sogar Kahneman selbst hat zugegeben, dass es ihm passiert ist, als er das Buch über kognitive Verzerrungen schrieb. Hat Jahre länger gedauert als geplant. Die Ironie ist fast zu perfekt.
Solitaire, Atombomben und dein Sprint-Backlog
1946 erholte sich ein polnischer Mathematiker namens Stanislaw Ulam von einer Gehirnoperation (Enzephalitis, übles Zeug) und spielte viel Solitaire. Er fragte sich ständig: wie hoch ist die Wahrscheinlichkeit, dass dieses Blatt gewinnt? Er versuchte es analytisch zu berechnen. Ging nicht. Zu viele Permutationen. Und dann hatte er eine dieser Ideen, die im Nachhinein offensichtlich erscheinen, aber irgendwie alles verändern — was wäre, wenn ich einfach tausend Spiele spiele und zähle, wie viele ich gewinne?
Er erzählte seinem Kollegen John von Neumann davon. Von Neumann, weil er von Neumann war, sah sofort die Anwendung auf die Neutronendiffusionsprobleme, an denen sie in Los Alamos arbeiteten. Der Name musste geheim bleiben, also nannten sie es "Monte Carlo" nach dem Casino, in dem Ulams Onkel gerne spielte. Und das war's — das ist die ganze Technik. Versuch nicht, die exakte Antwort zu berechnen. Simulier das Ding wie verrückt und schau was passiert.
Für agile Lieferprognosen ist es der gleiche Trick, nur auf deine Sprint-Daten angewandt statt auf nukleare Kettenreaktionen (wohl weniger stressig, obwohl manche Daily Meetings nah dran kommen):
- Nimm den Throughput deines Teams aus den letzten Sprints — wie viele Elemente ihr jeweils abgeschlossen habt
- Sag dem Simulator, wie viele Elemente noch übrig sind
- Der Simulator wählt zufällig einen Throughput aus deiner Historie, zieht ihn von der restlichen Arbeit ab, wählt einen neuen, zieht wieder ab, und macht weiter bis die Arbeit bei null ist
- Macht das 10.000 Mal
- Sagt dir: "von 10.000 Simulationen, hier ist wie viele Sprints es gedauert hat"
Keine Story Points. Kein Planning Poker. Keine "aber ist eine Login-Seite eine 3 oder eine 5?"-Debatten um 9 Uhr morgens an einem Montag. Nur deine echten Daten, durch Zufall gejagt, die eine Spanne realistischer Ergebnisse produzieren.
P50, P85, P95 — drei Zahlen, die alle unsere Diskussionen ersetzt haben
Was dich am Ergebnis interessiert sind drei Perzentile:
P50 — die Hälfte der Simulationen war zu diesem Sprint fertig. Münzwurf. Das nutze ich für interne "wäre schön"-Planung. Verpflichte dich damit nie nach außen.
P85 — 85% der Simulationen waren zu diesem Sprint fertig. Das ist die Zahl, die ich Managern sage, sie sollen sie nehmen. Wenn dein VP nach einem Termin fragt, ist das der Termin. Nicht der optimistische. Dieser.
P95 — 95% der Simulationen waren zu diesem Sprint fertig. Verträge. Angebote. Alles, wo einen Termin zu reißen echtes Geld kostet. Bis hierher puffern und nachts ruhig schlafen.
Aber hier ist das, worüber niemand redet: die Lücke zwischen P50 und P95 ist die wertvollste Information überhaupt. Wenn P50 sagt 7 Sprints und P95 sagt 8, ist dein Team eine Maschine. Konstant, vorhersehbar, langweilig auf die beste Art. Wenn P50 sagt 6 und P95 sagt 14? Dann hast du ein Problem, das keine Schätztechnik der Welt lösen wird. Dein Throughput ist chaotisch und du musst rausfinden warum, bevor du dich um das Wann sorgst.
Ich hatte mal ein Team, wo die Spanne von 5 bis 19 ging. Neunzehn Sprints. Für dasselbe Backlog. Wir haben nachgeforscht und festgestellt, dass zwei ihrer Sprints null Throughput hatten — das gesamte Team war beide Male in die Incident Response gezogen worden. Als wir diese Daten rausnahmen (es waren Einzelereignisse, kein Normalbetrieb), schrumpfte die Spanne auf 6 bis 9. Viel brauchbarer.
Was der Code wirklich macht
Der Simulator läuft in deinem Browser. Nichts geht an einen Server. Ich bin da ein bisschen besessen — wenn deine Sprint-Daten auf deinem Rechner bleiben können, sollten sie auf deinem Rechner bleiben. Sie werden auch in localStorage gespeichert, damit du nicht nächste Woche alles neu eingeben musst.
Die Simulationsschleife ist fast peinlich simpel:
for (let i = 0; i < iterations; i++) {
let remaining = totalItems;
let sprints = 0;
while (remaining > 0) {
// Zufälliger Sprint aus deiner Historie
const throughput = data[Math.floor(Math.random() * data.length)];
remaining -= throughput;
sprints++;
}
sprintCounts.push(sprints);
}
Das ist... im Grunde alles. Jede Iteration wählt zufällige Throughput-Werte aus deiner Historie bis die Arbeit erledigt ist, und notiert wie viele Sprints es gedauert hat. Sortiert alle 10.000 Ergebnisse, liest die Perzentile ab. Die Mathe ist trivial. Die Erkenntnis nicht.
Was das Ganze funktionieren lässt ist, dass es nichts glättet. Hattest du einen furchtbaren Sprint, in dem du nur 3 Elemente geschafft hast? Das wird gesampelt. Hattest du einen unglaublichen, in dem du 20 abgeräumt hast? Wird auch gesampelt. Die Simulation bewahrt die gesamte hässliche Realität der Performance deines Teams, statt sie hinter einem Durchschnitt zu verstecken.
Ich hatte es satt, dass Tools dich nicht vor schlechten Daten warnen
Einer meiner größten Kritikpunkte an allen Monte-Carlo-Tools, die ich ausprobiert habe, bevor ich mein eigenes gebaut habe: sie schlucken Müll mit einem Lächeln und spucken ein vertrauensvoll aussehendes Diagramm aus. Gib ihnen zwei Datenpunkte und sie liefern dir P50/P85/P95 als ob diese Zahlen bei einer Stichprobe von zwei irgendetwas bedeuten würden.
Also habe ich fünf Prüfungen eingebaut, die dich anschreien wenn deine Daten fragwürdig sind:
Wenn du nur 2 oder 3 Sprints hast — es läuft, aber es warnt dich, dass die Ergebnisse im Grunde Rauschen sind. Du brauchst mindestens 8-10 Sprints damit das Gesetz der großen Zahlen anfängt für dich zu arbeiten.
Sprints mit Null-Throughput werden markiert. Nicht weil sie ungültig wären (Feiertage passieren, Blocker passieren), sondern weil aus Versehen 0 statt 10 einzutippen deine Prognose ruiniert und du es vielleicht nicht mal bemerkst.
Wenn ein Sprint 50 Elemente zeigt während dein Median bei 12 liegt, markiert das Tool es als wahrscheinlichen Ausreißer. Vielleicht hat das Team massenhaft alte Tickets geschlossen. Vielleicht waren sie wirklich so produktiv. In jedem Fall solltest du es dir anschauen.
Wenn alle deine Werte identisch sind — sagen wir exakt 10 Elemente jeden Sprint — sagt dir das Tool im Grunde "du brauchst mich nicht, die Antwort ist eine Division." Was, naja, stimmt.
Und wenn dein Variationskoeffizient über 50% liegt, warnt es dich, dass dein Throughput volatil ist und die Spanne breit sein wird. Das ist kein Tool-Problem. Das ist ein Team-Prozess-Problem. Meistens sind es Scope-Änderungen mitten im Sprint, oder Leute die in verschiedene Richtungen gezogen werden, oder Abhängigkeiten von anderen Teams die unberechenbar sind. Beheb die Ursache, dann starte die Prognose.
Ein Beispiel mit echten Zahlen
Nehmen wir an, die letzten 10 Sprints deines Teams sahen so aus — und ich wähle realistische Zahlen, keine aus dem Lehrbuch:
| Sprint | Erledigt |
|---|---|
| 1 | 8 |
| 2 | 12 |
| 3 | 10 |
| 4 | 7 |
| 5 | 14 |
| 6 | 11 |
| 7 | 9 |
| 8 | 13 |
| 9 | 6 |
| 10 | 11 |
80 Elemente im Backlog. Du gibst das in den Monte-Carlo-Simulator ein und startest ihn.
P50 kommt bei 8 Sprints raus. P85 bei 9. P95 bei 11.
Jetzt sagst du dem PM statt "ungefähr 8 Sprints, denke ich?": "Wir sind zu 85% sicher, dass es in 9 Sprints fertig ist. Wenn du eine Garantie brauchst, plane mit 11. Ich würde extern nicht weniger als 9 versprechen." Der PM hat etwas womit er arbeiten kann. Etwas mit angehängten Konfidenzniveaus. Wenn er sich auf 9 festlegt, macht er eine informierte Wette, keine blinde.
Und ehrlich gesagt ändert sich das Gespräch komplett. Statt darüber zu streiten, ob 8 Sprints "ambitioniert genug" sind (ein Satz, den mir tatsächlich mal ein PM gesagt hat, verfolgt mich bis heute), redet ihr über Risikotoleranz. Was von Anfang an das Thema hätte sein sollen.
Story Points, ich hab euch lieb, aber wir müssen reden
Ich habe jahrelang Story Points benutzt. Fibonacci, T-Shirt-Größen, das volle Programm. Ich war Überzeugungstäter. Ich habe sogar auf Twitter mit Leuten darüber gestritten. Ich lag falsch. Oder zumindest habe ich eine bessere Option übersehen.
Story Points wurden erfunden, um Schätzung von Zeit zu entkoppeln. Komplexität schätzen, Velocity messen, Timeline ableiten. Elegant in der Theorie. In der Praxis?
Die Schätz-Meetings. Oh Gott, die Schätz-Meetings. Fünfundvierzig Minuten debattieren, ob die Migration des Auth-Service eine 13 oder eine 21 ist. Die Senior-Entwicklerin denkt, es ist eine 13, weil sie es schon mal gemacht hat. Der Junior denkt, es ist eine 21, weil er gesehen hat, wie der Auth-Service aussieht. Beide haben aus ihrer Perspektive recht und die Zahl, auf die sie sich einigen (meistens gewinnt der Lautere), hilft niemandem bei der Planung.
Und die Velocity in Punkten-pro-Sprint ist seltsam instabil. Sie driftet. Teams kalibrieren unbewusst ihre Schätzungen, um eine Velocity-Zahl zu treffen, mit der ihr Manager zufrieden scheint. Ich hab das gesehen. Niemand gibt es zu, aber es passiert.
Monte Carlo umgeht das einfach... alles. Du zählst erledigte Elemente pro Sprint. Keine Punkte, keine Stunden. Elemente. Fertig oder nicht fertig. Binär. Der Input ist objektiv und der Output ist probabilistisch und das gesamte Schätz-Meeting verschwindet aus deinem Kalender. Allen Holub und die #NoEstimates-Leute sagen das seit Jahren. Monte Carlo ist die Mathematik, die ihr Argument konkret macht.
Wann dieser Ansatz scheitert
Ich wäre ein schlechter Ingenieur, wenn ich dir nicht sagen würde, wann man das NICHT benutzen sollte.
Dein Backlog wächst ständig? Monte Carlo kann nicht helfen. Wenn du 15 Elemente pro Sprint hinzufügst und 10 fertigstellst, ist die einzig ehrliche Prognose "nie." Bring erstmal den Zufluss in Ordnung.
Dein Backlog ist ein wilder Mix aus völlig unterschiedlich großen Elementen? Ein Ticket ist "Typo auf der 404-Seite fixen" und ein anderes "den Checkout-Flow neu designen"? Elemente zählen ist sinnlos. Du musst Dinge aufbrechen bis sie ungefähr vergleichbar sind. Ehrlich gesagt solltest du das sowieso machen, aber Monte Carlo erzwingt es.
Dein Team hat sich gerade drastisch verändert? Neue Leute, Abgänge, Reorg? Deine historischen Daten repräsentieren nicht dein aktuelles Team. Wirf sie weg und fang neu an. Ich weiß, das tut weh. Die Simulation nimmt an, dass die Zukunft der Vergangenheit ähnelt. Wenn die Vergangenheit irrelevant ist, ist es die Simulation auch.
Winziges Backlog? So 5 Elemente? Der Unterschied zwischen einem "guten Sprint" und einem "schlechten Sprint" ist riesig im Verhältnis zum Ganzen. Monte Carlo funktioniert am besten mit 30+ verbleibenden Elementen, wo der Zufall sich über viele simulierte Sprints ausgleicht. Bei 5 Elementen... mach sie einfach. Du wirst sehen wann sie fertig sind.
Loslegen — dauert etwa 90 Sekunden
- Öffne den Monte-Carlo-Lieferprognose-Simulator
- Gib den Throughput der letzten 8-10 Sprints ein (nur die Anzahl erledigter Elemente pro Sprint — schau in Jira oder Linear nach wenn du dich nicht erinnerst)
- Gib die verbleibenden Backlog-Elemente ein
- Drück auf Start
Das war's. Komm nächsten Sprint wieder, füg die neue Zahl hinzu, schau wie sich die Prognose verändert. Deine Daten bleiben in deinem Browser — ich habe nicht mal einen Server, an den ich sie schicken könnte.
Wenn dich agiles Tooling interessiert, haben wir auch einen Sprint-Kapazitätsrechner gebaut, um zu planen wie viel Arbeit dein Team wirklich übernehmen kann, ein MoSCoW-Priorisierungs-Board für gnadenloses Triage, und einen Kumulativen Flussdiagramm-Generator um zu sehen wo Arbeit steckenbleibt. Alles kostenlos, alles im Browser, kein Konto nötig.
Für Nerds: was mathematisch passiert
(Überspring das wenn dich Statistik nicht interessiert. Ich urteile nicht.)
Was wir machen ist ein Bootstrap-Resampling. Wir ziehen Stichproben mit Zurücklegen aus einer empirischen Verteilung — deiner Throughput-Historie — und verwenden diese Stichproben um einen Parameter zu schätzen der uns interessiert, nämlich Liefertermin-Perzentile. Es ist nichtparametrisch, was bedeutet, dass wir nicht annehmen, dass deine Daten einer Normalverteilung oder irgendeiner anderen theoretischen Form folgen. Gut so, denn Sprint-Throughput-Daten sind so gut wie nie normalverteilt. Sie sind meist rechtsschief mit gelegentlichen Nullwerten.
Warum 10.000 Iterationen? Bei 1.000 wackeln deine Perzentilschätzungen etwas zwischen den Durchläufen. Bei 10.000 stabilisieren sie sich. Bei 50.000 verbrennst du Rechenleistung für vernachlässigbare Verbesserung. Der zentrale Grenzwertsatz garantiert Konvergenz, aber die Geschwindigkeit hängt von der Varianz deiner Daten ab — Teams mit wilden Throughput-Schwankungen brauchen mehr Iterationen zum Stabilisieren. 10.000 ist der Sweet Spot für so ziemlich alle.
Eine Designentscheidung, mit der ich zufrieden bin: die Simulation nutzt diskretes Resampling (zufällig echte historische Sprints wählen) statt eine kontinuierliche Verteilung anzupassen. Manche Tools nehmen an, Throughput sei normalverteilt, und sampeln aus einer angepassten Gauß-Verteilung. Mathematisch sauberer, aber falsch. Deine Daten haben eine Form. Vielleicht bimodal, weil du zwischen Crunch-Sprints und Erholungs-Sprints wechselst. Vielleicht mit einem langen Schwanz, weil einmal im Jahr alles aus dem Ruder läuft. Diskretes Resampling bewahrt die tatsächliche Form deiner Daten. Keine Annahmen, keine Überraschungen.
Die unbequeme Wahrheit, die dieses Tool aufdeckt
Ich schließe mit etwas, das mir aufgefallen ist, nachdem ich Dutzende Teams damit habe arbeiten sehen.
Das Tool sagt dir nichts, was du nicht schon wusstest. Es macht nur unmöglich, es zu ignorieren.
Diese breite Spanne zwischen P50 und P95? Das ganze Team hat das Chaos schon gespürt. Sie konnten es nur nicht beziffern, also wurde es nie zum Gesprächsthema. Diese Ausreißer-Sprints? Die Leute erinnerten sich daran, konnten aber nicht artikulieren, warum sie für die Planung wichtig waren. Die Tatsache, dass sich auf P50 festzulegen ein Münzwurf ist? Im Grunde haben alle geahnt, dass die Deadline unrealistisch war. Niemand hatte die Daten, um dagegenzuhalten.
Monte Carlo nimmt das vage Gefühl, dass "unsere Schätzungen meistens daneben liegen" und verwandelt es in "wir sind zu 85% sicher bei 9 Sprints und hier ist das Diagramm." Es verschiebt das Gespräch von Bauchgefühl zu Wahrscheinlichkeit. Und da fangen die Dinge an sich zu ändern.
Wenn du immer noch jedes Sprint Planning Poker spielst und mit einer Zahl rauskommst, an die eigentlich niemand glaubt, versuch mal eine Simulation. Nur einmal. Gib deine echten Daten ein und schau was sie sagt. Das Schlimmste was passieren kann ist, dass sie bestätigt was du schon wusstest. Das Beste was passieren kann ist, dass sie dir die Munition gibt, um endlich ein ehrliches Gespräch darüber zu führen, wann das verdammte Ding fertig wird.
Probier es hier aus. Kostenlos. Deine Daten verlassen nicht deinen Browser. Und es dauert weniger als eine Runde Planning Poker.