An eight-person engineering team spends two hours every two weeks in planning poker. Arguing over whether a ticket is a 5 or an 8 routinely eats fifteen minutes on its own. Someone references a similar ticket from three sprints back, someone disagrees, the cards go around a second time. Twenty minutes later the team lands on 8 points. A week later the product owner is asked by leadership when the billing module ships. The answer that reaches the executive team contains no reference to points — it contains a date and a dollar figure. The points the team debated never made it into the room where the actual decision was made.
This is not an edge case. It is the default operating mode of most organizations that adopted story points as their standard estimation unit under agile delivery. Points live in the backlog, in burndown charts, and in sprint retrospectives. Management decisions — whether to greenlight a project, when to commit a date to a client, how many engineers to add to a team — live in an entirely different system: calendar dates and figures on invoices. This article explains why the two systems never actually connect, what that costs an organization, and what to do instead.
What is story point estimation and why was it introduced?
Story points emerged as an answer to two problems with hourly estimation: pressure toward a precision nobody could actually deliver, and a recurring conflict between an engineer’s honest estimate and a manager’s need for a commitment. The Fibonacci-like scale (1, 2, 3, 5, 8, 13…) was designed to force relative thinking — “this ticket is roughly twice as complex as that one” — instead of absolute claims like “this will take me 6 hours and 15 minutes.” Planning poker, popularized by Mike Cohn and James Grenning, was built as a team calibration tool, not as a reporting mechanism aimed at leadership.
The trouble starts the moment an organization starts treating points as a currency convertible into time. Team velocity — points closed per sprint — becomes the multiplier used to translate the backlog into months: “we have 400 points left, we clear 40 a sprint, so that’s ten sprints.” That arithmetic looks solid on a slide. In practice it assumes the complexity distribution of the next two hundred tickets matches the complexity distribution of the twenty tickets closed in the last two sprints — an assumption that rarely survives contact with a project running longer than a quarter.
What management decisions actually get made?
Leadership and clients make three kinds of decisions based on engineering output: when something ships (a date), what it costs (a budget), and whether it is worth doing at all relative to other bets (an investment priority). None of the three is expressed in points. A client contract states a delivery date, not a point total. A CFO’s quarterly budget states a dollar amount, not a sum of story points planned for the quarter. A board asks whether an investment pays back within eighteen months, not whether the backlog weighs 800 or 950 points.
Points have to be converted into these three units before they enter the decision conversation. That conversion usually happens once, when the roadmap is first built, and is rarely re-run every time the team’s velocity shifts. The end result is that a leadership decision rests on a points-to-date conversion made months earlier, not on the current state of the backlog’s point total. The engineering effort spent refining the estimate of each individual ticket has no bearing on a decision that was already locked in based on an earlier approximation.
Do story points actually feed those decisions?
Formally yes — there is a path from a point to a date, running through velocity. Practically, that path bleeds precision at every one of three conversion steps. First, the estimate of a single ticket carries a wide error band on its own — research into software estimation accuracy, including Steve McConnell’s well-documented “cone of uncertainty,” shows that at sprint-planning time the error on a single ticket’s estimate can run tens of percent in either direction. Second, team velocity swings sprint to sprint for reasons that have nothing to do with estimation quality — vacations, production incidents, context switching between projects. Third, the backlog’s composition shifts mid-flight — new tickets get added, others get cut, a client’s priorities move.
The combined effect of these three error sources over a quarter is that a points-to-date conversion carries a wide confidence interval that almost nobody presents to leadership as an interval — it gets presented as a single date. That single date becomes a commitment, regardless of how much precision went into estimating the individual tickets that fed it. Precision at the ticket level does not translate into precision at the roadmap level, because the errors do not cancel out cleanly — under real project conditions they compound unevenly, usually toward delay rather than away from it.
What does the data say about estimation accuracy?
Industry reporting has documented the same pattern for decades: IT projects systematically overrun their original estimated budget and timeline, regardless of the estimation methodology used at kickoff. The Standish Group’s CHAOS reports, across successive editions, have repeatedly shown that even agile-run projects — with their regular, iterative point-based re-estimation — finish outside the original budget more often than the quality of individual ticket estimates alone would predict. That is not evidence that estimators are incompetent. It is evidence that the mechanism converting points into a timeline commitment is structurally fragile, no matter how carefully the team scores each ticket.
A separate, well-documented issue is “point inflation”: over time, teams unconsciously start scoring the same class of ticket higher than they used to, which pushes velocity up and makes sprint metrics look better — while quietly destroying the comparability of points over time. When velocity rises purely because the same work is now labeled with bigger numbers, a points-to-date forecast built on current velocity becomes misleading in a way no additional planning-poker training will fix.
Why do teams keep running planning poker anyway?
If points do not reliably feed leadership decisions, why does the ritual persist? Three forces keep it alive regardless of its effectiveness. First is institutional inertia — planning poker is baked into the definition of “being agile” in many organizations, so dropping it reads as abandoning agile altogether, which triggers cultural resistance stronger than any efficiency argument. Second is a genuine side benefit of the ritual — the conversation during estimation often surfaces scope misunderstandings before an engineer starts building, and that value is real, but it does not require attaching a number to it — a scoping conversation works without the card game.
The third force is the most expensive one: the absence of a trusted alternative the team already knows. Managers who have learned to read burndown charts and velocity reports have no ready substitute when someone proposes dropping points, and uncertainty about upward reporting is a stronger brake on change than the ritual’s actual value to the team. That closes a loop: the ritual persists because nobody has an alternative in hand, and nobody looks for one because the ritual formally “works” — the backlog is pointed, the charts render, the retros happen.
What does the estimation theater actually cost?
Run the numbers. An eight-person team spending two hours in planning poker every two weeks logs sixteen person-hours per sprint, roughly 26 two-week sprints a year — 416 person-hours annually spent purely on estimation sessions. At a blended engineering rate in the $50-90/hour range for a distributed or nearshore team, that is roughly $21,000-$37,000 a year for one team, before adding the management time spent translating points into roadmaps, board decks, and plan revisions whenever velocity drifts from assumptions.
That is the direct number. The indirect cost is harder to price but just as real: a false sense of precision. Leadership looking at “94 points left this quarter” in a tool like Jira reads that as a hard fact, not as an approximation with a wide error margin. That false precision drives commitments made with less safety margin than the project’s actual uncertainty would justify — and the cost of a broken delivery date to a client usually dwarfs the cost of the estimation sessions themselves.
What is the difference between estimating and forecasting?
The distinction that gets lost in most estimation debates is the one between estimating and forecasting. Estimating answers “how complex is this ticket” — it is inherently subjective, based on expert judgment, and applies to a single unit of work before it starts. Forecasting answers “when will this set of tickets be done” — it can be an empirical process, grounded in historical delivery data, and does not require pre-scoring the complexity of every element individually.
Organizations stuck in estimation theater try to answer a forecasting question using an estimation method — summing subjective complexity judgments across dozens of tickets and expecting the sum to yield a reliable date. Statistically, individual errors do not cancel cleanly under correlated disruption (the same root causes — skill gaps, technical debt, scope churn — hit many tickets at once), so a sum of imprecise estimates does not become precise just because it is long.
How does throughput replace points for forecasting dates?
The alternative used by teams moving away from points — a movement known as #NoEstimates, associated with Woody Zuill and Vasco Duarte among others — bases the forecast on throughput: the number of tickets a team closes per unit of time, measured empirically from its own history, with no requirement to estimate complexity before work starts. Instead of asking “how many points does this ticket weigh,” the team breaks work into pieces of roughly comparable size (each ticket fits within one to two days of effort) and measures how many such pieces it closes per week.
On top of that data, teams run a Monte Carlo simulation: the model draws thousands of scenarios from the historical throughput distribution and returns not a single date but a probability distribution — “there is an 85% chance the 60-ticket backlog is done by November 14.” This method requires no planning-poker session at all. It does require discipline in breaking large tickets into comparably sized pieces — a practice that is good backlog hygiene regardless of which forecasting method a team uses.
What happens when a team drops points?
Teams that switch to throughput-based forecasting report two effects fairly quickly. First is reclaimed time — planning sessions shrink because the conversation moves from “how many points is this worth” to “do we understand the scope and can we break it down,” a shorter and more productive discussion. Second is a shift in stakeholder conversations — instead of a single date presented as a certainty, the team starts presenting probability ranges, which feels uncomfortable at first but builds more trust over time, because commitments made with visible uncertainty break less often than ones presented as guarantees.
A side effect organizations only appreciate a few months in: throughput as a metric is far more resistant to manipulation than velocity built on points. Points can be inflated to make a chart look better. The number of tickets actually shipped and deployed in a week is much harder to fake without a real change in pace — making it a more trustworthy signal for leadership than any velocity chart.
What are the real risks of dropping point estimation?
The change is not free, and that needs to be said plainly. Throughput-based forecasting needs a reasonably stable, fairly uniform stream of small tickets — it performs worse on projects with high variance in work size (one three-week research spike sitting next to ten one-day tickets) without first breaking large items down. It also requires a degree of process maturity in backlog decomposition — a team that cannot split an epic into pieces that fit in a few days will not benefit from this method without doing that groundwork first.
The second risk is cultural: switching forecasting methods without first explaining to stakeholders why the old method was misleading tends to read as a loss of planning control rather than an improvement to it. Communicating this change to leadership — with concrete data on the historical gap between point-based estimates and actual delivery dates — matters as much as the forecasting switch itself.
What does a delivery-planning maturity map look like?
| Maturity level | How planning works | Main risk | Next step |
|---|---|---|---|
| 1. Hourly estimation | Engineers state hours per ticket, summed directly into a schedule | Pressure to “hit” unrealistic estimates, overtime | Introduce relative estimation (points) for team calibration |
| 2. Story points as ritual | Team scores tickets, velocity tracked per sprint, but points are never checked against actual delivery pace | False precision at the roadmap level, point inflation | Start measuring throughput in parallel with points for 2-3 months |
| 3. Points and throughput in parallel | Team still points tickets, but delivery decisions start relying on actual completion-rate data | Two reporting systems can drift apart and confuse stakeholders | Replace point-based forecasts with Monte Carlo forecasts built on throughput |
| 4. Empirical forecasting (throughput/Monte Carlo) | Backlog broken into comparably sized pieces, forecast delivered as a probability range grounded in historical data | Requires discipline decomposing large tickets and educating stakeholders on confidence intervals | Extend the method across the project portfolio, not just one team |
How do you roll this out without causing organizational chaos?
Changing the forecasting method does not require a one-time revolution. The most reliable path, observed in teams that made this transition without organizational pushback, runs a parallel measurement period: the team keeps running planning poker for two to three months, but starts collecting throughput data alongside it — the number of tickets closed per week. After that window, the two forecasts get compared retrospectively: which method’s predicted date landed closer to the actual delivery date. In the large majority of documented cases, throughput wins that comparison, which gives the team a concrete argument for the stakeholder conversation instead of relying on methodological conviction alone.
The next step is gradually retiring planning poker in favor of a shorter scoping conversation, while keeping monthly throughput reports for stakeholders framed as probability ranges rather than single dates. Organizations that roll this out without first educating leadership on what a confidence interval means risk having the change read as “the team stopped taking planning seriously” — which is why the communication layer of this change matters as much as the methodology itself.
Key takeaways
Story points are not inherently useless, but in most organizations they perform a function they were never built for — a currency converted into the dates and budgets presented to leadership. That function fails systematically, because error compounds across three independent conversion steps: single-ticket estimation, velocity variance, and backlog scope drift. The result is a ritual that costs real engineering time — tens of thousands of dollars a year for a typical eight-person team — without a proportional improvement in the accuracy of the decisions actually being made from dates and budgets, not points.
The throughput-based alternative does not eliminate project uncertainty — it makes that uncertainty visible instead of hiding it behind a single number that looks precise but rarely is. For organizations that want to check whether their current estimation process actually translates into delivery accuracy, the first step is a simple retrospective audit — comparing estimated dates against actual delivery dates over the last four to six quarters. If ARDURA’s team can help run that audit and design a forecasting process grounded in data instead of ritual, get in touch — our Software Development team works with organizations going through exactly this transition.