Story points are the most widely used unit of estimation in agile teams, and one of the most misunderstood. Ask most teams why they point their backlog, and the honest answer drifts toward "so we can predict when things will be done" — velocity charts, sprint forecasts, burndown lines, all built on the assumption that a point total translates into a calendar date. It's a reasonable-sounding assumption. It's also not what points were ever built to do.
What story points actually measure
A story point is a relative, pre-work judgment — a guess, made by the team, before anyone has touched the ticket, that blends complexity, effort, and uncertainty into a single number. That's genuinely useful for what it's designed for: prioritization conversations, relative sizing ("is this roughly a 3 or roughly an 8"), and trade-off discussions about what fits in a sprint. None of that requires the number to be accurate in an absolute sense. It only requires the relative ordering to be roughly sensible.
The trouble starts when that same number gets asked to do a second job it was never designed for: predicting how many actual days a ticket will take to close.
The correlation that isn't there
Points drift. A "5" assigned by one team means something different from a "5" assigned by another, and — less obviously — a "5" assigned by the same team six months ago doesn't reliably mean the same thing as a "5" assigned by that team today. Team composition changes, familiarity with the codebase changes, and the informal calibration that made points feel consistent quietly drifts along with it.
Even holding the team and the time period constant, the chart above shows the deeper problem: tickets pointed identically at creation routinely take wildly different amounts of actual time to close. A "5-point" ticket might take two days or fifteen, depending on whether it got blocked on a review, waited behind other work in progress, or ran into a dependency nobody could see at estimation time. None of that is visible when the point value is assigned — which is exactly the point. Points are estimated before the work happens; the things that actually determine how long a ticket takes mostly happen after.
This connects directly to why WIP is the number that actually predicts cycle time — a ticket's actual duration has far more to do with how much else is competing for attention while it's open than with how big anyone guessed it would be beforehand.
Cycle time doesn't estimate the future — it counts the past
Cycle time is different in kind, not just in accuracy. It's not a judgment made in advance; it's a measurement taken after the fact — the number of days between when a ticket actually started and when it actually finished. It requires no calibration meeting, carries no team-specific "what does an 8 mean here" ambiguity, and doesn't drift the way a point scale drifts, because it isn't a scale at all. It's just elapsed time, observed.
That's exactly why it's the right raw material for a Monte Carlo forecast and points aren't. A forecast built from a distribution of real cycle times carries all the actual variance of how work moves through this team — the blockers, the review queues, the interruptions — because those things already happened and are baked into the number. A forecast built from story points would have to invent that variance from scratch, because points are collected before any of it occurs.
This isn't an argument to stop pointing
Pointing still earns its keep for what it's actually good at: sizing conversations, scope trade-offs, deciding what reasonably fits in a sprint. The argument here is narrower and more specific — points shouldn't be the input to a delivery date. Ticket-level cycle time and throughput should be, because they're the only one of the two that's actually been observed rather than guessed.
There's a broader habit worth naming here too: a team that's had a string of underestimated tickets doesn't need to "correct" its next few point values upward, as if the estimate itself were somehow due for a swing back toward accuracy. That's the same reasoning error a coin flip makes when it's "due" for tails after a run of heads. The fix isn't a better guess. It's measuring the thing that can actually be measured, instead of trying to out-guess a number that was never built to predict a calendar in the first place.