Complete firstKanban
Flow system with consistently measured throughput or cycle time for at least 6-12 weeks.
Without: Without historical data, simulation cannot draw plausible distributions; forecast becomes random noise.
RunsheetDelivery
Monte Carlo Forecasting
ComplexityHigh
Time30-90 min Setup, danach laufend
Participants1-8
FormatWorkshop + async
MaturityEstablished
01
Prerequisite
What needs to be finished first
Complete firstStory Splitting
Work items are sliced similarly enough that historical items are comparable with future items.
Without: With very heterogeneous items, simulation mixes apples and oranges; percentiles become unreliable.
02
Preparation
What needs to be ready before start
Materials
Throughput or cycle-time dataset as CSV or sheet; Monte-Carlo tool (Actionable Agile, Throughput Forecaster, Python script, Excel with random functions); forecast questionnaire; stakeholder-briefing documentation.
People / roles
One analyst (Tech Lead, Flow Master, or coach) who extracts data and runs simulation; one Product Owner as forecast requester; team for assumption plausibility checks; optional sponsor.
Pre-read
Concrete forecast question ("When done?" or "How much by date X?"); historical throughput data; remaining scope (number of items); known anomalies in data window (holidays, outages, hires/aborts).
Time needed
30-90 min setup, then 15-30 min per forecast
Setup
Fix the data window (rule of thumb: at least 11 points, typically 12 weeks). Mark anomalies. Configure tool for 1000+ simulations. Phrase forecast question precisely (scope, target date, probability).
03
Core question
The one question this method answers
With what probability will the desired scope be finished by the target date (or how much scope can we complete by then), and which assumptions drive the distribution?
04
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Refine forecast question | 10-15 min | Choose one of two standard questions: "When are N items done?" or "How many by date X?" Fix scope and target date. Set confidence threshold (typically 70% or 85%). | Unclear questions create unclear answers. Treat multiple concurrent questions separately. No probability statement without threshold. |
2Phase 2: Check and clean data set | 15-20 min | Pull throughput data from last 6-12 weeks. Flag or exclude anomalies (holidays, outages). Check representativeness: does data match the upcoming period? | "Garbage in, garbage out." Data quality is forecast quality. When team structure changes, collect new data; ignore old data. |
3Phase 3: Run simulation | 5-10 min | Start the tool with 1000+ simulations. For "when done," randomly draw weekly throughput per simulation and accumulate until scope is reached. For "how much," draw each week until target date. | At least 1000 simulations, otherwise percentiles are too coarse. In tools with built-in options, pay attention to distribution type (resampling from historical data is best practice). |
4Phase 4: Evaluate and communicate percentiles | 15-20 min | Calculate percentiles: 50%, 70%, 85%, 95%. Phrase communication as a probability statement: "85% chance done by date X." List assumptions explicitly. | A point estimate without probability is incorrect. "We deliver by 15.06." is wrong; "85% probability by 15.06." is correct. |
5Phase 5: Update weekly | 10 min per week | Add one new data point each week and recalculate forecast. Document trend: does the 85% value move forward or backward. | A stagnant or moving-back 85% value is an early warning sign. Investigate scope growth, throughput decline, or item delay as causes. |
05
Artifact
What comes out at the end
Form
Forecast document with forecast question, data window, percentiles, distribution chart, assumption list, and status date. Weekly updates with trend. Linked to flow dashboard.
Versioning / ownership
Archive one snapshot per forecast date. Keep trend table with date and 50%/70%/85%/95% values and scope status. Change forecast question => create a new forecast ID; do not overwrite old.
Tool alternatives
- Actionable Agile (commercial SaaS)
- Throughput Forecaster (free Excel version)
- Python with numpy.random.choice for resampling
- R with custom simulation scripts
- Custom dashboard in Tableau or PowerBI
monte-carlo-forecasting-working-template.md
Compact working template for Monte Carlo Forecasting with context, input, output artifacts, and next step.
Monte Carlo Forecasting Working Template
Goal
Predicts delivery time or scope probabilistically using historical throughput or cycle time data.
Context
When and for what do we use this method?
Input
Which data, observations, decisions, or materials are available?
Execution
Short notes along the runsheet.
Output artifacts
- Forecast Percentiles:
- Throughput Dataset:
- Risk Communication:
Assumptions and open questions
- ...
Decision / Next step
Owner, date, and success signal.
06
Example output
Concrete filled scenario, fictional example
monte-carlo-forecasting-beispiel.md
Concrete filled scenario, fictional example
Monte Carlo Forecast - Webhook System v1, 2026-05-18
Forecast question: When will Release "Webhook System v1" (18 remaining items) be finished?
Data window: Throughput last 12 weeks, items/week: 5, 7, 6, 4, 8, 6, 5, 7, 6, 5, 6, 7. Median 6, min 4, max 8. No anomalies.
Simulation: 10,000 runs, resampling from 12 weekly values.
Percentiles
- 50%: 3.0 weeks (08.06.)
- 70%: 3.3 weeks (10.06.)
- 85%: 3.6 weeks (12.06.)
- 95%: 4.0 weeks (15.06.)
Communication: "With 85% probability, Webhook System v1 is done by 12.06. At 95% confidence, by 15.06."
Assumptions: Team setup unchanged, no tech migration, slicing remains disciplined, 18 items are not split into larger work chunks.
Trend (3-week comparison): 85% value was 4.2 weeks three weeks ago, now 3.6 weeks. Acceleration from better slicing.
07
Pitfalls
Recognize symptoms and steer against them
Trap
Percentile point becomes a delivery guarantee
Symptom
Stakeholder reads the 85% value as a committed date; delay is treated as breach of trust.
What to do
Consistently state probabilistic output: "85% chance of X, 15% chance of delay." Educate stakeholders that probabilistic forecasts include built-in variation.
Trap
Wrong data window
Symptom
Data includes structural changes (new tech stack, team doubling), and the distribution does not match the next period.
What to do
Ignore old data windows after structural change. Collect at least 4-6 weeks of new data before forecast is valid. Communicate forecast in between with lower confidence.
Trap
Heterogeneous items
Symptom
Items vary heavily by size (tasks to epics mixed), making throughput counts unreliable.
What to do
Enforce slicing rules. Count epics or spikes separately or consistently as "1 item." Pause forecasting until slicing is fixed if heterogeneity is too high.
Trap
Forecast not updated
Symptom
Week 1 forecast is quoted in week 6 despite new data being available.
What to do
Introduce weekly forecast cadence. Include status date in forecast. Clearly label stale forecasts as outdated.
Trap
Scope grows during forecast
Symptom
Forecast is optimistic, but remaining scope grows and delivery date is missed despite valid throughput projection.
What to do
Run scope tracking in parallel. Recalculate forecast when scope changes. Treat scope growth as separate early warning signal.
08
Stop criteria
Done signals checkable in under a minute
Fewer than 6 weeks of flow data available, resampling base too small.
Items vary strongly by size, throughput counts are not meaningful.
Team or tech stack changed significantly recently, historical data no longer matches.
Stakeholder does not accept probabilistic statements and insists on a single date.
Scope changes significantly during forecast window and assumptions no longer hold.
Initiative is a single project without comparison data; forecast has no base.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.