Story Points Got an Apology From the Man Who Invented Them

Story points were invented to answer one narrow question, which was how much work to pull into the next iteration. They were never meant to be a productivity measure, a cross-team comparison, or a forecast you could hand a board. Ron Jeffries, one of the original signatories of the Agile Manifesto, put it plainly in a 2019 essay revisiting the idea. "I may have invented story points, and if I did, I'm sorry now." What he recommends instead is slicing stories small enough that estimating them stops mattering, sized by a single acceptance test.

That last part is the useful bit. It swaps a number you guess for a condition you can check, which is more rigor rather than less.

What story points were actually for

Points started life in Extreme Programming under a different name. The standard estimation guidance still describes them roughly as they were originally taught. They were "ideal days," meaning the amount of work a developer could do in a day with no interruptions. The name changed because stakeholders kept asking why three real days were needed to deliver one ideal day of work, which is a reasonable question with an awkward answer.

Jeffries is direct about the scope of the original intent:

"We really only used the points to decide how much work to take into an iteration anyway."

That is the whole job. Points were a capacity heuristic for a two-week planning conversation, nothing more. Every use that came later, including velocity targets, team-to-team comparison, and quarterly forecasting, was bolted on afterward by people who needed a number and found one lying around.

If you want the vocabulary underneath all of this, we have a separate breakdown of how initiatives, epics, stories, and tasks relate.

Where story points break

Four failures, and they compound.

Points become hours anyway. The rename was supposed to prevent this and it did not. Most teams settle into a fixed conversion within a sprint or two, at which point you have hours with extra steps and a layer of deniability.

Velocity becomes a target. The moment a velocity number is reported upward, it stops measuring and starts being managed. Estimates inflate, and they inflate honestly, because the incentive is invisible to the people responding to it.

Points measure effort, and effort is not value. A five-point story that nobody uses and a two-point story that unblocks a customer look like a 5 and a 2 on the board. Nothing in the system knows the difference, which is the same failure as counting lines of code.

Estimates get less accurate as the work gets less certain. They are most confident on well-understood work, where you needed them least, and least reliable on novel work, where the forecast actually matters.

None of that is new criticism. What is new is that the ground underneath the practice moved.

What AI-assisted delivery does to story points

Points estimate human effort. When part of the implementation is done by an agent, effort decouples from both time and difficulty in ways the scale cannot represent.

A change that would have been a comfortable five points, meaning several days of careful human work, can now be an hour of agent output followed by a review problem. A one-point change to an unfamiliar service can still take a week, because the constraint was never typing speed. The scale was calibrated against a relationship between difficulty and duration that no longer holds consistently, and no amount of recalibrating the Fibonacci sequence fixes that.

The second effect is subtler and more important. Bryan Finster, who created MinimumCD.org and founded the DevOps Dojo at Walmart, pointed out on Stacked Sessions that the reason to keep work small now applies to the implementer as well as the estimator:

"That cognitive load for humans is a real thing also for agents. If you start giving an excessive cognitive load, that's when you start getting hallucinations. It'll get amnesia. You'll get less accurate results."

So the size of a slice has become a quality input rather than a scheduling detail. An oversized piece of work does not just take longer to estimate accurately. It produces worse output, whoever builds it.

What replaces story points

Here is the part worth sitting with. Jeffries and Finster came at this from opposite ends, twenty years apart, and landed in the same place.

Jeffries recommends slicing stories down until each one takes very little time, ideally under a day, and using a single acceptance test as the sizing guide. If a story needs more than one acceptance test, it is more than one story.

Finster runs a team confidence vote against a similar threshold. Before work is committed, every person on the team answers one question:

"Does everybody agree that they could pick up any one of these scenarios that we've listed out here and complete it in two days or less? And if the answer was no, then we would keep refining."

Both replace an estimate with a binary condition you can check. Not "how big is this," which invites negotiation, but "is this small enough and clear enough that anyone here could finish it," which has a yes or no answer and a defined next action when the answer is no.

The mechanics of that are the same as behavior-driven development, where the acceptance tests are the acceptance criteria rather than a separate list. One slice, one testable behavior, stated as a concrete starting state, one action, and one observable outcome.

The practical difference is where the conversation goes. Estimation asks the team to predict. Slicing asks the team to clarify. The first produces a number that will be wrong; the second produces a shared understanding that makes the number unnecessary.

What to measure instead of velocity

Dropping points leaves a reporting gap, and pretending otherwise is how these transitions fail. Three things fill it better than velocity did.

Count questions asked mid-implementation. Finster's framing is the sharpest metric in this whole area:

"If you had to ask questions, that was a defect in a refining process."

An engineer stopping to ask what was meant is evidence the slice was underspecified, and it is free to capture because those questions already happen in Slack and in tickets. It is also the mechanism behind the finding that half of product and engineering teams report ticket quality causing drag.

Track cycle time on real work rather than estimated size. How long a slice actually takes from start to deliverable tells you what points were trying to approximate, measured rather than predicted. Our breakdown of cycle time against flow time covers which one answers which question.

Track slice count and rework. How many slices landed, and how many came back. That pair says more about a team's throughput and quality than a velocity chart, because neither number can be inflated by an estimating conversation.

[Editorial note. Add one Allstacks platform figure here before publishing, ideally the correlation between story point estimates and actual cycle time across accounts. If that correlation is weak, the sentence stating it becomes the most citable thing on the page.]

How to move off story points this sprint

You do not need a process change approved to try this. Run it inside your existing refinement.

Add the confidence vote to your next refinement, and keep estimating as normal. Ask whether every person could pick up any item on the list and finish it in two days. Record the answer alongside your usual points. Do this for two sprints and you will have your own evidence about which signal predicted reality better.

Split anything that needs more than one acceptance test. That is Jeffries' rule and it is mechanical. It requires no judgment about size and no negotiation, which is exactly why it works where estimation does not.

Start logging clarifying questions against the refinement that produced them. One column in a spreadsheet. The number will be higher than you expect, and it will point at specific items rather than at people.

If sprint planning currently ends with a points total and no confirmation that anyone could pick up any item, the estimate is doing work the refinement should have done.

‍

Allstacks Product Studio is where product and engineering define, refine, and share specs grounded in the real codebase, customer voice, and delivery history, sized against your team's actual delivery patterns rather than an estimate.Tree for Free!