How Flexion thinks about story sizing

Clients often ask us at Flexion how we size user stories in agile software delivery. A user story, or simply a “story,” is agile’s unit of work: a small piece of functionality described from the user’s point of view, in the familiar form “As a caseworker, I want to filter my queue by county, so that I can focus on my region’s cases.” A story counts as done only when it works at production quality, through every technical layer, integration, and policy requirement it touches. Behind the question are three legitimate needs: predicting the rate of progress, planning near-term work, and surfacing hidden technical challenges as early as possible. We share those goals completely. But our answer surprises people.

In most circumstances, we prefer not to size stories at all. After decades of delivery experience in legacy system modernization, we hold that position for reasons that are statistical, behavioral, and ultimately about protecting our clients’ outcomes.

Counting works as well as estimating story points

Start with the math. The purpose of story sizing, when it feeds a burn-up chart, is to project a rate of progress into a completion window. But the variation between estimates and actuals is large, and when work is prepared with discipline (more on that below), the statistical character of the story stream is stable over time. The mix of story sizes a team encounters next month looks like the mix it encountered last month. Under those conditions, a forecast built on a simple count of completed stories lands within the margin of error of a forecast built on carefully estimated points. Vasco Duarte’s #NoEstimates work demonstrated this across real project data: story count predicts as well as story points.

If two instruments produce the same forecast and one of them is free, paying for the other is a waste. The hours a team spends debating whether something is a three or a five buy no additional predictive power. The count is the estimate. In practice, because the story is the unit of work, the whole method is three steps: count the stories remaining, measure the rate at which the team actually completes them (its throughput), and extrapolate. A backlog of 120 stories and an observed pace of eight finished per week points to roughly fifteen weeks, quoted as a range that narrows as real data accumulates. Every number in that forecast is counted, not guessed.

Notice, though, that “when will we be done?” is only one of the questions throughput can answer, and it is the right question only when the scope is known in advance. In adaptive product development, it usually is not: stories emerge as the product meets real users, and the backlog a year from now contains work no one can name today. The instrument does not change in that world, but the reading does. The same measured pace that projects a completion window against a fixed scope instead answers what a team can deliver by a date, what a quarter of its capacity will buy, and, most importantly, whether the value coming out of each story still justifies continuing the investment.

The variance was never in the stories

There is a deeper reason estimation disappoints. Story sizing examines the feature, the part of the work that is visible in a refinement session. But the feature is not where the uncertainty lives. The biggest sources of variance are in the context: the technical landscape of the client’s environment, the political and social dynamics that shift priorities mid-flight, and the knowledge, cooperation, and availability of the specific people involved. In legacy system modernization, a whole additional layer of uncertainty sits underneath. Every undocumented or poor decision, workaround, constraint that built up over the life of the system is still in there, and none of it can be seen from a story card.

Point estimation, in other words, carefully measures the one part of the effort that was never the problem. Real throughput measures the whole system, feature and context together, because actual delivery data comes from reality rather than from inspection. Anyone who has lived through a large modernization knows the schedule was never killed by the features.

What happens when estimates become report cards

The statistical case says sizing is unnecessary. The behavioral case says it does active harm, and this is the part we have watched play out over and over.

When an organization holds a team accountable for the accuracy of its estimates (an accountability that reality cannot support), the estimate stops measuring the work and starts measuring self-protection. Teams pad their numbers so they won’t look unreliable. When the padding turns out to be unnecessary, they quietly fill the slack with extra activity rather than finish early and be seen as exaggerators. Real throughput falls. Leadership reads the slowness as underperformance and responds with hard milestone dates. When the inevitable surprises surface, the team cuts corners to hit those dates, and the piled-up technical debt makes the system brittle. The end state of holding teams accountable for estimates is the opposite of the intent: a fragile system that took longer to build.

None of this is unique to Flexion’s experience. It is a well-documented measurement problem, and the people who created these practices have said so plainly. Ron Jeffries, the inventor of story points, wrote in Story Points Revisited: “I may have invented story points, and if I did, I’m sorry now.” His diagnosis matches ours nearly word for word: estimates fuel pressure, pressure erodes quality, and the result is what he calls “a race to disaster” through defects and technical debt. Martin Fowler reaches the same conclusion from another direction: an estimate is only worth producing when it would change a significant decision, and in day-to-day delivery it rarely would.

The discipline that makes counting trustworthy

Forecasting by story count is not a free lunch. It is paid for upstream, through discipline in how work is identified and sequenced. That discipline is also our honest answer to the question of surfacing technical risk early.

We slice work into thin vertical slices of discrete user value, each running end to end through the real system. We apply YAGNI (“you aren’t gonna need it”) at every level, which pointedly includes not building out infrastructure ahead of need. As a result, infrastructure work and the surprises that always come with it are spread across the whole timeline instead of concentrated in a big up-front build or a big-bang integration at the end. Integrations, the usual cause of outsized stories, are likewise spread across the delivery by the way we select and order stories.

This has two effects worth stating separately. First, it keeps the delivery data statistically stable. Surprises arrive at a roughly constant rate, so the burn-up’s slope already has them priced in, and the projection stays honest without anyone estimating anything. There will always be stories of varying size that we cannot identify in advance. That is normal. Variance only damages a forecast when it clusters, and the slicing discipline exists to prevent clustering.

Second, it means the riskiest unknowns (authentication, deployment pipelines, legacy data, cross-system integration) are encountered in the first slices, in the first weeks, because the delivery order forces early contact with them. Traditional estimation tries to predict where the difficulty lies. Slicing plus YAGNI arranges for difficulty to be met at a steady rate from day one. Hidden technical challenges surface at the earliest possible moment, not because someone guessed at them in a planning meeting, but because the way we structure the work guarantees we run into them early. This is also exactly the practice Jeffries recommends in place of pointing: slice stories small, count them, and deliver continuously.

Where estimation genuinely earns its keep

There is one situation where relative sizing is not just acceptable but vital: when multiple business stakeholders are competing for a single team’s attention. The naive alternative is to let the delivery team arbitrate whose priority wins. That puts the team in a no-win position it is neither qualified nor positioned to occupy, doubly so for an external vendor. Someone is always angry at the referee.

The durable solution is to get stakeholders to agree on a system of prioritization, one step removed from the individual priority decisions themselves. We use an approach we call Value-Flow Rate, our variant of Don Reinertsen’s Weighted Shortest Job First. Each candidate item gets value points, which capture cost of delay (“how much does it hurt each day this isn’t in production?”), and duration points. Items are then ranked by the ratio of value to duration. The duration points capture everything that adds lead time, including cross-team dependencies, approvals, and queues, not just development complexity. That is consistent with our view that the context, not the feature, is where the time goes.

Something delightful happens under this system: stakeholders start cutting their own scope. Trimming low-value extras shrinks the denominator and moves an item up the list, so competition drives features toward their minimum viable form without any pleading. And the imprecision of these estimates is harmless here. The stakes are about ranking, not about the calendar. A rough size that is off by forty percent rarely changes a ranking, while the same error in a schedule commitment ignites the padding spiral described above. Estimation fails when it is asked to predict dates. It succeeds when it is asked to compare options.

When story sizing is required anyway

Some organizations mandate story sizing, and when they do, we comply, with our effort focused on reducing the harm. The essential safeguard is keeping points strictly relative: “this will take about twice as long as that,” never a mapping to hours or days. Relative points carry no false precision to be graded against, so the uncertainties get absorbed into the numbers over time. And because our slicing discipline spreads surprises evenly across stories, the relative scale stays internally consistent and the projections factor in the surprises automatically.

The failure mode to guard against is the organization “helping” by correlating points to units of time. The moment one point equals four hours, points become commitments, commitments invite accountability, and the whole spiral of padding, pressure, and brittleness begins again. We will size stories if required. But decades of experience, and the recent consensus of the people who invented these techniques, say it is the wrong tool for the job it is usually asked to do.

The short version

We do not refuse to estimate. We insist on measuring what actually informs decisions. For forecasting, disciplined slicing plus real throughput predicts completion windows as well as pointing ever did, at zero ceremony cost, while forcing the riskiest work into the earliest weeks. And when scope is emergent rather than known in advance, as it usually is in adaptive product development, the same throughput tells you what a date will hold and whether continued investment is still paying for itself. For prioritization among competing stakeholders, lightweight relative estimation inside an agreed system maximizes delivered value and keeps everyone out of no-win arbitration. And where sizing is mandated, we keep it relative and harmless. Predictability, sprint planning, and early risk discovery are not casualties of this approach. They are its products.