Was vorher fertig sein muss
Ein Kanban-System oder vergleichbarer Flow-Prozess mit Throughput- und Cycle-Time-Daten der letzten 6-12 Wochen liegt vor.
Das Team kann Items konsistent klein schneiden (Faustregel: <5 Tage Cycle Time), Splitting-Techniken sind bekannt.
Was vor Start vorliegen muss
Flow-Dashboard mit Throughput und Cycle Time (Jira, Linear, Azure DevOps oder externes Tool wie Actionable Agile); Backlog mit kleingeschnittenen Items; Forecast-Tool oder Monte-Carlo-Simulator; Liste der typischen Planungsfragen.
Ein Flow-Master oder Tech Lead, der Daten pflegt und Forecasts kommuniziert; das umsetzende Team; ein Product Owner für Slicing und Priorität; optional ein Coach für Methodenwechsel.
Throughput-Daten (Items/Woche) der letzten 6-12 Wochen; Cycle-Time-Verteilung; aktueller WIP; Slicing-Regeln; bekannte Planungsfragen (Release-Termin, Budget, Scope).
laufend, Setup 30-60 min, Forecast 15-30 min
Throughput-Daten als Datensatz exportieren. Forecast-Tool konfigurieren (Monte Carlo mit 1000+ Simulationen). Definition „kleine Story“ festlegen. Aktuelle Schätz-Rituale identifizieren, die ersetzt werden sollen.
Die eine Frage, die diese Methode beantwortet
Welche Planungsentscheidung wollen wir treffen, und welche Flow-Daten oder Slicing-Regeln liefern die Antwort billiger als ein Schätzritual?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Planungsfrage formulieren | 10 min | Konkret benennen, welche Entscheidung Schätzung unterstützen soll: Release-Termin, Budget, Scope-Schnitt. Pro Frage prüfen, ob Flow-Daten reichen. | Ohne konkrete Frage ist NoEstimates dogmatisch. Manche Fragen brauchen echte Schätzung (z. B. unbekannte Investitionen). Antworten ehrlich pro Fall. |
2Phase 2: Slicing schärfen | 20-30 min | Aktuelle Items prüfen, ob sie klein genug sind (Cycle Time < 5 Tage). Splitting-Regeln dokumentieren (z. B. „Item ist klein, wenn ein Entwickler es in 3 Tagen abschließen kann“). | Ohne kleines Slicing zählt Throughput Äpfel und Birnen. Wenn 30% der Items >5 Tage Cycle Time haben, erst Slicing fixen, dann Forecast. |
3Phase 3: Throughput-Daten sammeln | 15 min | Pro Woche Anzahl abgeschlossener Items zählen. Mindestens 6-12 Wochen. Cycle-Time-Verteilung dazu. Anomalien (Feiertage, Outages) markieren. | Datenfenster muss zur Frage passen. Für Quartals-Forecast 12 Wochen, für Sprint-Forecast 4-6 Wochen. Saisonale Effekte berücksichtigen. |
4Phase 4: Forecast erzeugen und kommunizieren | 15-30 min | Monte-Carlo-Forecast für Planungsfrage. Perzentile berechnen (50%, 70%, 85%, 95%). Range kommunizieren: „85% Wahrscheinlichkeit, in 5 Wochen fertig“. | Forecasts altern. Wöchentlich aktualisieren. Bei System-Veränderung (neuer Engineer, Migration) altes Datenfenster verwerfen. |
Was am Ende rauskommt
Flow-Dashboard mit Throughput-Chart und Cycle-Time-Verteilung; Forecast-Dokument pro Planungsfrage mit Perzentilen und Annahmen; Slicing-Regeln im Team-Wiki; Liste der ersetzten Schätzrituale.
Throughput-Daten als Zeitreihe gepflegt (z. B. Sheet mit Datum, abgeschlossene Items). Forecasts pro Planungsfrage mit Datum archivieren, alte nicht löschen. Slicing-Regeln im Wiki versioniert.
Kompakte Arbeitsvorlage für NoEstimates mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# NoEstimates Arbeitsvorlage
## Ziel
Ansatz, der explizite Aufwandsschätzung reduziert und stattdessen kleine Items, Durchsatz und Forecasting nutzt.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Throughput Data:
- Flow Forecast:
- Slicing Rules:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## NoEstimates - Release-Forecast Q3/2026, 2026-05-18
**Planungsfrage**: Wann ist das Release „Webhook-System v1“ wahrscheinlich fertig? Restscope: 18 Items.
**Slicing-Status**: 16 von 18 Items sind klein (Cycle Time historisch <4 Tage). 2 Items als Splitting-Kandidat markiert.
**Throughput**: Letzte 12 Wochen: 5, 7, 6, 4, 8, 6, 5, 7, 6, 5, 6, 7 Items/Woche. Median 6, Min 4, Max 8.
**Monte-Carlo-Forecast (1000 Simulationen)**
- 50%: 3,0 Wochen
- 70%: 3,3 Wochen
- 85%: 3,6 Wochen
- 95%: 4,0 Wochen
**Kommunikation**: „Mit 85% Wahrscheinlichkeit liefern wir bis 11.06. Bei Slicing der zwei großen Items reduziert sich der 85%-Wert auf 3,4 Wochen.“
**Annahmen**: Aktuelles Team-Setup bleibt, keine größere Tech-Migration, Slicing bleibt diszipliniert.
**Folge-Aktionen**: Slicing-Workshop für die zwei großen Items am 21.05. (Owner: @lisa).Symptome erkennen, gegensteuern
Team weigert sich, jegliche Schätzung zu liefern, auch wenn Flow-Daten für die Frage nicht reichen.
NoEstimates ist Werkzeug, kein Glaubensbekenntnis. Bei neuen Initiativen ohne Flow-Daten kurz schätzen. Methode dort einsetzen, wo Daten tragen, sonst pragmatisch ergänzen.
Items variieren stark in Größe (1 Tag bis 3 Wochen), Throughput-Zählung wird nicht aussagekräftig.
Slicing-Regeln dokumentieren und einhalten. Items, die nicht kleinschneidbar sind, als „Spike“ oder „Epic“ getrennt zählen. Cycle-Time-Verteilung regelmäßig prüfen.
85%-Wert wird als Liefer-Datum interpretiert, Schwankungen werden zur Krise.
Konsequent Wahrscheinlichkeit kommunizieren, nicht Datum. Stakeholder-Edukation: 85% heißt 15% Chance auf Verzug. Forecast-Range immer mitliefern.
Forecast nutzt 6 Monate alte Daten, obwohl Team-Größe und Tech sich geändert haben.
Datenfenster regelmäßig prüfen. Bei Strukturwechsel (Team, Tech, Org) altes Fenster verwerfen und mit neuer Datenbasis starten. Mindestens 4-6 Wochen neue Daten vor Forecast.
Items sind so klein, dass einzelne keinen Nutzerwert liefern, Throughput sieht hoch aus, Outcomes stagnieren.
Slicing muss vertikal bleiben (Wert pro Item). Wenn Items rein technische Subtasks sind, Wert wird nicht geliefert. Slicing-Regeln mit Wertkriterium ergänzen.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.