Forecast delivery dates without estimating a thing

Ask an engineer when something will ship and watch them flinch. Not because they don't know the work, but because the question demands a single date and the honest answer is a range. So they pad, or they guess, or they convene a planning-poker session to convert a feeling into a number that feels rigorous and isn't. The whole apparatus of estimation exists to manufacture a confidence we don't actually have — and then we're surprised when the date it produces turns out wrong.

There's a better way to answer 'when will it ship?' that's both more honest and less work: forecast probabilistically from data you already have. Instead of a date, you produce a distribution — a 50% chance by here, an 85% chance by there — and you commit at whatever confidence the situation calls for. No story points required.

A date with no probability is a guess in a suit

The core problem with a single-date estimate is that it hides its own uncertainty. 'We'll be done on the 20th' sounds precise, but it omits the only thing that matters: how likely is that? If it's a 50/50 coin flip, committing to it externally is reckless; if it's a near-certainty, sandbagging to the 27th wastes a week. The date alone can't tell you which, so it can't actually inform a decision — it just feels like it does.

A probabilistic forecast restores the missing information. 'An 85% chance of finishing by the 24th' tells a stakeholder exactly how much risk they're accepting, and lets them choose: take the aggressive date at lower confidence for an internal stretch, or the conservative one at higher confidence for a customer promise. Same underlying reality, but now the uncertainty is on the table instead of buried inside a false-precision number.

How Monte Carlo forecasting actually works

The method is far simpler than its intimidating name. Take your team's recent throughput — how many work items it completed each week — as a sample of how it really behaves. To forecast finishing some number of remaining items, randomly draw a week's worth of completions from that history, then another, and another, accumulating until the work is done, and record how many weeks it took. That's one simulated future. Do it ten thousand times and you get not one answer but a distribution, because each run draws a different sequence of good weeks and bad ones.

That distribution is the forecast. Sort the ten thousand outcomes and read the percentiles: the date by which half the simulations finished is your 50% line, the date by which 85% finished is your 85% line. The bad weeks — the ones with an incident, a holiday, two people out — are already baked in, because they're in the historical sample you drew from. This is the quiet superiority of the approach: it doesn't forget the interruptions that every single-number plan optimistically ignores.

Counting beats estimating

The part that surprises people is that you can throw away story points entirely and forecast on raw issue count, and it usually works better. The reason is statistical: when you complete dozens of items, the big ones and the small ones average out, and the law of large numbers does the smoothing that per-item estimation tries and fails to do. A team that simply counts 'we finish about eight issues a week' has a more reliable forecasting input than a team that painstakingly assigns points, because the points add a layer of guesswork without adding accuracy.

The one discipline this requires is keeping issues roughly similar in size — splitting the giant ones so no single item dominates a week. That's a healthy habit regardless: a too-large issue is a planning risk and a flow risk, and breaking it down is exactly what good backlog refinement does anyway. Do that, and counting completed items is all the estimation your forecast needs.

The one assumption, and how to keep it honest

Monte Carlo forecasting makes a single assumption: that the near future will resemble the recent past. When a team is stable and the kind of work is consistent, that holds well enough to be useful. It breaks when something structural changes — half the team rotates off, or the work shifts from familiar features to an unfamiliar platform migration — because then the historical sample no longer describes the team that's doing the work. The fix isn't to abandon the method; it's to be aware of when your history stopped being representative and to weight recent weeks more heavily.

Keeping the forecast honest is mostly a matter of feeding it fresh data. Every finished week becomes another sample, so the forecast naturally tracks the team's real, current pace rather than a stale snapshot. The failure mode to avoid is the same one that corrupts velocity: turning the forecast into a target. The moment 'finish by the 85% date' becomes a goal people are measured against, they'll game the inputs, and a measurement that's being gamed has stopped measuring anything.

Forecasting as a built-in, not a spreadsheet

None of this requires a data scientist or a side spreadsheet that's out of date the moment you close it. The raw material — completion events, timestamped — is something a tracker already records every time an issue moves to done. The simulation is a few lines of arithmetic over that history. The reason most teams still estimate instead of forecast isn't that forecasting is hard; it's that their tools surface points and burndown but not throughput and percentiles, so the easier, better method stays invisible.

Planoda charts throughput per period straight from completion events, which is the exact input a Monte Carlo forecast runs on — so 'when will it ship?' can be answered with a probability grounded in your team's real history, not a planning-poker number everyone privately doubts. Estimate less, count what you finish, and let the distribution tell you the truth about your dates.