No black boxes.
Every number Intervals shows comes from a simulation you can understand. Here is exactly how it works.
Why Monte Carlo?
Software scope and velocity are not constants — they are ranges. A single-date estimate pretends that everything will go exactly as planned, which is almost never true. Monte Carlo simulation runs the project 10,000 times, each time drawing a slightly different scope and a slightly different velocity from plausible ranges. The result is not one date but a distribution — a histogram of outcomes that shows you which dates are likely, which are optimistic, and which give you a true safety buffer.
The method was pioneered in software forecasting by Troy Magennis (Focused Objective). The cycle-based planning model is informed by Shape Up (Basecamp).
What happens in one run
Each of the 10,000 runs represents one plausible version of your project. Here is what happens inside a single run:
- 1.Sample scope. Draw a scope count from a triangular distribution over your low / likely / high estimates. Most samples land near “likely”; a few hit the extremes. This models the reality that rough estimates have fat tails.
- 2.Apply scope creep. Multiply by a factor drawn uniformly from your creep range. 1.0× means no creep; 1.5× means the team discovered ~half again as much work mid-project. Scope creep models the discovery that still lies ahead — it is not the same as recorded added actuals, which cover past discovery.
- 3.Build a throughput pool. In estimate mode, draw two samples uniformly from your throughput range. Using a small pool makes the spread between low and high throughput drive the fan-out of outcomes — a deliberate modeling choice. In historical mode, use your actual recorded completions as the pool.
- 4.Burn down. Each simulated cycle, randomly draw one throughput value from the pool and subtract it from remaining items. Count cycles until items reach zero. That cycle count is the run’s result.
What each input means
Scope estimate — low / likely / high
The number of items (stories, tickets, units) to ship. “Likely” is your best single guess; low and high are the plausible extremes. The triangular distribution clusters most runs near likely and puts progressively fewer runs toward the extremes.
Scope creep — multiplier range
How much extra work tends to surface after planning. Rough guidance:
- 1.0× — well-defined, little will change
- 1.2× — some items will split
- 1.5× — significant unknowns
- 2.0× — exploratory, expect a lot of discovery
The display shows you the implied count: “25 items × 1.3× creep ≈ 33 simulated.”
Throughput — items per cycle
How many items the team completes each cycle. Estimate mode takes a low/high range and draws two samples per run. Historical mode uses your actual recorded completions as the sample pool — so the simulation draws from real variance, not a guess.
Cycle length
How many weeks each cycle covers (2 weeks for sprints, 6 weeks for Shape Up cycles, etc.). Cycles are the unit the simulation counts; cycle length converts them to calendar dates.
The four confidence bands
Intervals never shows a single date. It shows four bands, each representing a different level of confidence:
| Band | Confidence | What it means |
|---|---|---|
| Optimistic | 50–70% | Early but plausible. Needs luck. |
| Likely | 70–85% | The realistic target. Most teams use this for internal goals. |
| Projected | 85–95% | Use for external commitments. |
| Conservative | 95%+ | A true buffer for the unexpected. |
“P85 = 12 cycles” means 85% of the 10,000 simulated futures finished in 12 cycles or fewer. The histogram lets you see the full distribution, not just the summary points.
Execution tracking and re-forecasting
Once work starts and you record actuals each cycle, the forecast updates to use what you have actually observed.
Remaining scope is your original scope estimate shifted by the net of items added minus items completed across all recorded cycles, clamped at zero. The spread (low/likely/high) is preserved; recorded history moves the whole estimate.
Throughput switch — the model makes a clean switch, not a blend:
- Cycles 1–2: the configured throughput range is used (not enough history yet).
- Cycle 3 onward: the simulation samples purely from your actual completed-per-cycle values.
- If every recorded cycle completed 0 items, the configured throughput is kept (a zero-only pool carries no velocity signal).
Blending (mixing configured and actual throughput) was deliberately rejected — it makes the model harder to explain and understand. You get exactly two phases: estimated, then observed.
Scope creep still appliesto remaining scope. Recorded “added” items cover past discovery; the creep multiplier models the discovery still ahead. Its absolute effect shrinks naturally as remaining scope burns down.
What to commit to
The right band depends on the stakes:
- Internal team goals — the Likely band (P70–P85) is realistic and still achievable without sandbagging.
- External commitments — the Projected band (P85–P95) gives you a real buffer. If the product ships earlier, that is a good surprise, not a problem.
- Never commit to Optimistic — 50–70% confidence means roughly half your simulated futures missed that date. It is not a safe public commitment.
Product-bets pipeline
The bets pipeline tracks whether your hypotheses were right — not just whether you shipped. A disproved bet that stops the team doing the wrong thing is a good outcome. Optimize for learning velocity, not win rate.
The five stages
Each stage has an exit criterion. A bet cannot advance without meeting it. Evidence is defined at Shaping — before any work — so the verdict at Proving is accountable rather than rationalized.
| Stage | Exit criterion |
|---|---|
| Shaping | Hypothesis · success criteria (metric, signal, threshold, timeframe) · owner · target landing date · effort |
| Shipping | Feature live in production for target users |
| Landing | Baseline metric captured |
| Proving | Success-criteria metric read against its threshold — a measured outcome reading that enables a verdict |
| Closed | Verdict recorded; proved and disproved also require learnings + the measured outcome reading |
Where bets die
Each stage-to-stage drop diagnoses a different failure mode. This is the hero metric — it tells you why bets fail, not just how many did.
| Drop | Diagnosis |
|---|---|
| Shaping → Shipping | Prioritization — bets shaped but never started |
| Shipping → Landing | Execution — started but never shipped |
| Landing → Proving | Instrumentation — shipped but measurement skipped |
| Proving → Closed | Accountability — measured but verdict never recorded |
Verdict semantics
Proved and disproved can only close from Proving — they require learnings and a measured outcome reading. Inconclusivealso closes from Proving — you measured but couldn’t call it (small sample, ambiguous signal); no learnings required. Abandoned and deprioritized can close from any stage — no evidence required.
The validation rate (proved ÷ closed) is informational — not a target to maximize. It is always shown alongside learning velocity so the team optimizes for calibrated learning, not a safe-looking win rate.
Calibration
A forecast is only useful if it is honest. Calibration measures whether your stated confidence actually matches reality over time: when you commit at P85, roughly 85% of those commitments should land within the promised cycle count. A higher hit-rate than your stated confidence means sandbagging — the forecast carries no information. A lower hit-rate means overconfidence — you are over-promising.
How a hit is defined
At the moment you commit a project at a confidence band, Intervals records the cycles already completed and the forecast’s remaining cycles at that band. The promised total is the sum of those two numbers. A commitment is a hitwhen the project’s actual total cycle count at completion is at or below the promised total. Every other outcome is a miss.
Per-band, not global
Different projects may be committed at different confidence levels (P50, P70, P85, or P95). Intervals tracks each band separately — a P85 history is never diluted by P50 commitments, and the diagnostic compares each band’s realized rate against its own stated target. A band needs at least two completed data points before a flag is raised; below that, the sample is too noisy to diagnose.
What the flags mean
| Flag | What it means |
|---|---|
| Overconfidence | Realized hit-rate is well below the stated target. Your forecasts are more optimistic than your track record supports. |
| Sandbagging risk | Realized hit-rate is well above the stated target. You are committing at a lower confidence than necessary — the forecast is not carrying useful information. |
The goal is neither the highest hit-rate nor a low one — it is a hit-rate that matches the stated confidence. A team that says “P85” and hits 85% of the time is well-calibrated, and that track record is the product’s credibility surface.
Not yet implemented
Two features are planned but not yet built:
- Staffing scaling (Brooks’s Law) — when you change team size, the simulation could apply a 0.85 exponent to throughput to model coordination overhead. Not built yet; the configured throughput is used as-is.
- Project dependencies — blocking one project on another for roadmap-level forecasting. Planned for a future phase.
Intervals will update this page when these ship.