✓-Zeilen = gelieferte Releases mit damaliger Prognose — der Track-Record der Methode.
| Ticket | Titel | Kategorie | Wartet | Prio | Bereich |
|---|
Der Rechner unten ist derselbe Monte-Carlo-Resampler wie im Report (Seed 42) — jede Änderung wird sofort mit 2000 Läufen neu simuliert.
Gleiche Logik, gleicher Seed wie die Report-Berechnung — die Basiszahlen oben sind exakt reproduzierbar.
| Ticket | Status | Typ | Prio | Titel |
|---|
| Ticket | Risk | Status | Prio | Titel | Bereich |
|---|
Ein offenes Review-Gate (79 % ohne Review) ist ein Nacharbeitsrisiko: Fehler tauchen später als Bugs im Scope wieder auf. Nur 35 % der PRs referenzieren ein Jira-Ticket — Jira misst die echte Arbeit also unscharf; das kostet Confidence (−10) und ist über alle drei Stichtage konstant.
Der Forecast ist ein Monte-Carlo-Resampling der eigenen Liefer-Vergangenheit: Pro Simulationslauf wird ab morgen täglich ein Wert zufällig (mit Zurücklegen, fester Seed 42) aus den zuletzt real beobachteten Tages-Lieferwerten gezogen, bis der Rest-Scope 0 erreicht. 2000 Läufe ergeben eine Verteilung von Fertigstellungsdaten, aus der P50/P85/P95 und der On-time-Anteil abgelesen werden. Keine Annahmen, keine Schätzungen — die eigene Vergangenheit, neu gemischt.
Wochenend-Nulltage bleiben im Pool (reale Tage). Batch-Tage (Release-Wellen) bleiben drin, werden aber markiert und in der Batch-Sensitivität separat ausgewiesen. Das Done-Datum kommt aus dem Status-Changelog (Jira liefert kein resolutiondate); Scope wird über Epics, Labels und Titel-Keywords geschnitten, weil keine fixVersions gepflegt werden. Blocker-Klassifikation über Status-Gates, Labels und „is blocked by“-Links.
Status-Ampel nach harten Schwellen aus dem On-time-Anteil: ≥ 85 % On Track · 60–84 % Tight · 30–59 % At Risk · 10–29 % High Risk · < 10 % Unrealistic. Farbe folgt der Schwelle, nie dem Bauchgefühl.