Story points can’t forecast a date — and were never meant to

Story points were invented to do one modest, useful thing: let a team compare the relative size of two pieces of work without arguing about hours. They were never designed to be multiplied, averaged, and projected into a calendar date you promise a customer. Yet that is exactly what most roadmaps do — take a velocity average, divide it into the backlog, and read off a date as if the number were a measurement rather than a shared guess. Then the date slips, everyone blames "bad estimation," and the team re-estimates harder next quarter. The problem is not the estimating. It is asking points to be something they are not.

Points measure size, and size drifts

The first crack is that estimates are most accurate when done by comparison and least accurate when done in isolation — and they only stabilize after a team has been together for several sprints. Even then, "stable" often just means the same degree of inaccuracy is applied consistently. Points are a snapshot of what the team understood at commitment. And what a team understands about a ticket almost always moves in one direction as reality arrives: upward. The 3 becomes a 5 mid-sprint when the edge cases surface. Nobody re-estimates down.

Estimates only churn one way under pressure — up. Which means committed points are denominated in hope, and until you convert hope to history, every forecast built on them inherits the bias.

Velocity quietly counts the same work twice

The second crack is carryover. When a ticket spills from one sprint to the next, naive velocity credits its points in both sprints it touched — so a team that recycles a fifth of its work every sprint looks roughly 20% faster than it is. Your roadmap consumes that inflated number and over-promises accordingly. The honest measure — "fresh velocity" — counts each ticket once, in the sprint it actually completes. It is almost always lower than the number on the velocity chart, and it is the only one you can safely plan a date around.

The commitment you measure isn’t the commitment you shipped

The third crack is the sneakiest, and it is baked into the tools. Jira computes "committed" as the total at the instant the sprint starts; scope added after that is not counted against the commitment, and scope quietly removed is not counted either. So the number you retrospect against is not the work the team actually carried — it is a frozen snapshot that drifted from reality the moment the sprint began. Any calibration you do against it is calibrating against fiction. You need a scope-change ledger that records what was added and removed after commitment, or your "estimate vs actual" is comparing the estimate to a different sprint.

What to denominate a forecast in instead

None of this means estimation is worthless — it means the forecast should be denominated in outcomes, not points. Three numbers do the real work, and a team can recompute all of them by hand from its own history:

• Optimism factor — final estimate ÷ original estimate, over your closed work. If it is 1.15×, your points are 15% "hope points"; pad the roadmap by that, not by folklore.
• Fresh throughput — each ticket counted once, on final completion, so recycled carryover stops inflating the plan.
• Cycle time, in business days — how long work actually takes from start to shipped, so a date rests on measured flow instead of a size proxy.

A story-point average will always be a comforting single number, and single numbers are exactly what a probabilistic future refuses to be. If you want a date you can actually stand behind, stop asking points to predict it. Measure the drift, count the throughput honestly, and forecast in a range with a probability attached — the approach in "Monte Carlo vs velocity." KalMatrix computes each team’s optimism factor, fresh velocity, and cycle time automatically from the Jira and Git history you already have, and shows you exactly which numbers to trust and which to caveat.