The Forecast Was Always Wrong

Not because your team is bad at estimating. Because estimating was never going to work.

Every software team has run this retrospective. A sprint commitment slips. Someone asks why. The answer lands somewhere in a small, familiar rotation: the story was under-sized, a dependency surprised us, someone got pulled onto a production fire. The team resolves to estimate more carefully next time. Two sprints later, the same conversation happens again, with a different excuse wearing the same shape.

The usual response to this pattern is to try to fix the estimating. Better planning poker discipline. More detailed acceptance criteria before sizing. A recalibration session to realign what a "3" means versus a "5." All of this treats the problem as a skill gap — as if a sufficiently disciplined team would eventually produce estimates that hold up.

They wouldn't. The problem was never a skill gap. It's a structural one, and it's worth actually walking through why, because once you see the mechanism, it stops looking like bad luck and starts looking like the predictable output of the process itself.

The orthodoxy: estimate, sum, commit

The standard workflow looks like this. Before a sprint starts, the team sizes each piece of work — story points, ideal days, T-shirt sizes, the label doesn't matter. Those estimates get summed into a sprint's worth of committed work, calibrated against the team's historical "velocity" — the average number of points completed per sprint over some recent window. The commitment gets presented to stakeholders as something close to a promise: this is what will be done, by this date.

It feels rigorous. It involves data, discussion, a number on a board. It has the shape of an engineering process.

The mechanism: why the shape is misleading

Here's what that process actually is, stripped of its ceremony: a single point estimate, built by summing several other single point estimates, each of which carries real uncertainty that the summing step quietly discards.

Consider one ticket. When a team sizes it, they're not measuring a fixed quantity — they're guessing at a distribution of possible durations, most of which cluster around some typical case, with a long tail of possible complications: an API that doesn't behave as documented, a test environment that's flaky, a dependency on someone else's unfinished work. A "3-point story" isn't really 3 points. It's a range, compressed into a single number because the process demands a single number.

Now sum ten of those compressed ranges into a sprint commitment. The compression doesn't cancel out — it accumulates. Some tickets will land near their typical case. Some will hit the long tail. The sprint's actual outcome depends on how many tickets land in which part of their own distribution, which is exactly the information that got thrown away the moment each estimate became a single number.

Velocity doesn't fix this. Averaging past sprint totals gives you a central tendency, but a central tendency isn't a forecast — it's a description of what happened on average, applied forward as if the next sprint is guaranteed to be an average one. Some won't be. The framework has no way to tell you which, or by how much, or with what confidence. It produces one number and calls it a plan, when what it actually has is a distribution wearing a single number's clothes.

This is why "estimate better" doesn't solve it. You can improve the accuracy of any individual size, and the sprint commitment will still be wrong on a predictable cadence, because the failure isn't in the sizing — it's in collapsing a distribution into a point before you've asked the question a distribution is actually good at answering: what's the probability of finishing by a given date?

What the data already knows

Here's the part that tends to get missed: teams already have the information needed to answer that question properly. It's not the story points. It's the delivery history.

Every team that's shipped anything has a record of how many tickets it actually completed, week over week, regardless of what anyone estimated beforehand. That number — real, historical throughput — is messier than a velocity average, and that messiness is exactly the point. It contains the good weeks and the bad weeks, the blocked days and the productive sprints, in their actual proportion. Nothing about it has been compressed into a single misleading figure.

This is the foundation of flow-based forecasting, an approach most clearly laid out in Daniel Vacanti's work on flow metrics and probabilistic forecasting. The core move is simple to state and easy to underestimate: instead of asking anyone to size the remaining work, run a simulation against the team's actual historical throughput, many times over, and read the answer off the resulting distribution of outcomes.

Concretely: pull however many weeks of real throughput history exist. Run several thousand simulated futures, each one drawing randomly from that real history and accumulating completed tickets until the remaining work would be finished. Record how many weeks each simulated future took. Sort the results.

What comes out the other end isn't a single date — it's a genuine probability curve. Half of the simulated futures finish by one date. Eighty-five percent finish by a later one. Ninety-five percent finish by a later one still. Nothing was estimated. Nothing was guessed. The team's own history did all the work, run forward ten thousand times instead of averaged once.

Why the range is the honest answer

The instinct to resist this is understandable: a range feels like a hedge, and stakeholders want a date, not a hedge. But a single committed date was never actually more honest — it was just more comfortable, right up until it slipped, at which point the discomfort arrived anyway, later and with interest, in the form of a retrospective nobody enjoys.

An 85% confidence date isn't a hedge. It's a precise, falsifiable claim: run this same team forward from this same starting point many times, and this is where most of those futures land. It can be wrong, and when it is, it's wrong in a way you can actually reason about — because you know what confidence level you committed to, rather than discovering after the fact that a single-point estimate was, structurally, always going to be wrong some of the time.

The teams that adopt this approach tend to describe the same shift: stakeholder conversations stop being about defending a date that was never really defensible, and start being about trade-offs inside a known, honest range. That's a better conversation. It's also the one the data actually supports.

Where this leads

None of this requires a new tool. A team can pull its own throughput history into a spreadsheet and run this simulation by hand — plenty do. The mechanism matters more than the implementation.

For what it's worth, this is the reasoning PtahCast was built around — a Kanban board with this kind of forecasting built into the data model itself, so the throughput history the simulation needs is already there, rather than something exported and reassembled by hand every time someone asks "when will this be done?" But the argument above doesn't depend on that tool, or any tool. It depends only on treating your team's real delivery history as more trustworthy than a guess made before the work started — because it always was.

If you've ever had to defend a date you didn't actually believe in, this is the reason it happened, and the reason it doesn't have to keep happening.