Picture a sprint where a coding agent drafts the code for a 5-point story before the refinement meeting is even over. The question follows naturally: if writing the code costs almost nothing, what are story points still measuring? This article belongs to our guide on Planning Poker and AI, and it describes the state of play as of October 2026.
Two camps have formed. One says story points are dead, because velocity explodes and no longer means anything. The other says points still work, provided they measure the human work that remains around the code. We look at what changed, what the evidence says, and how to keep estimating in a way that helps the team plan.
Are story points still useful when AI agents write the code?
Yes, if they size what the team still has to do, not the typing. A story point is a relative measure of the effort, complexity and uncertainty needed to deliver a story, and it was never a count of lines of code. When an AI coding agent drafts the implementation, the effort moves rather than disappears: someone has to specify the story precisely enough for the agent, review the generated code, test the edge cases, integrate it with the rest of the system and fix what breaks. The 2025 DORA report found that AI adoption now improves delivery throughput but still hurts delivery stability, which is exactly the work an estimate must cover. Story points lose their meaning when a team keeps its old reference stories and lets velocity inflate, or when it tries to point the agent's own output. They stay useful when the team recalibrates its references and asks one question during Planning Poker: how much human work does this story still need?
Why do some teams say story points are dead?
The argument comes from three directions.
Velocity stops meaning anything. A post on the Scrum.org blog in January 2026 argues that when AI reduces drafting effort to near zero while verification stays complex, velocity becomes "a vanity metric". It proposes replacing velocity with an "Agent Efficiency Score" that tracks how often agents finish work without human correction.
Points were designed for humans. Daniel Vaughan, writing in April 2026, argues that points measure human cognitive load, uncertainty and fatigue, which agents do not have. He describes teams splitting their backlog into an agent track, a human track and a hybrid track, and forecasting agent tasks with token budgets and compute time instead of points. This is an emerging practice, not an established method.
The inventor already had doubts. Long before agents, Ron Jeffries, one of the creators of Extreme Programming, wrote in 2019 that story points began as "ideal days" renamed to avoid confusion, and that he was sorry if he invented them. He recommends slicing stories very small and delivering often, rather than refining estimates.
These critiques share a point worth keeping: if a team uses points to measure output or compare productivity, AI breaks that use for good. But that use was already a misuse. Points were meant to help a team decide how much work to take on and to surface disagreements before the work starts.
What does the research say about AI and developer speed?
The evidence is less clear-cut than the headlines, which matters for anyone trying to recalibrate estimates.
| Study | What was measured | Main finding |
|---|---|---|
| METR, July 2025 | 16 experienced open-source developers, 246 real issues, randomized with or without AI | Tasks took 19% longer with AI, yet developers believed afterwards that AI had made them 20% faster |
| METR, February 2026 | A larger follow-up with late-2025 tools | Results judged unreliable because many developers refused to work without AI; METR thinks developers are probably faster now but calls its data very weak evidence |
| DORA, September 2025 | Survey of nearly 5,000 technology professionals | 90% use AI at work, more than 80% feel more productive, 30% have little or no trust in AI-generated code; AI adoption is linked to higher throughput but lower stability |
Three lessons follow for estimation:
- Feeling faster is not being faster. The METR gap between perceived and measured speed is a warning against recalibrating points from impressions. Use completed stories, not the team's sense of acceleration.
- Gains are uneven. METR's own caveats insist that its results apply to one setting and one period. A boilerplate migration and a subtle concurrency bug will not benefit in the same way, which is precisely the kind of difference relative estimation captures.
- The bottleneck moves downstream. DORA calls AI an amplifier: it magnifies a team's strengths and its weaknesses. More code arriving faster puts pressure on review, testing and deployment. If those steps are missing from the estimate, the sprint plan will be wrong.
What should a story point measure when an agent writes the code?
The work around the code. The table below compares where effort goes in a typical story before and after a coding agent joins the team.
| Part of the story | Without an agent | With an agent | Keep it in the estimate? |
|---|---|---|---|
| Clarifying the need and acceptance criteria | Discussed in refinement | Must be written precisely enough for an agent to act on | Yes, often larger |
| Writing the code | Main share of the effort | Largely drafted by the agent, with a few iterations | Partly: prompting and reworking |
| Code review | Reviewing a colleague's familiar code | Reviewing more code that nobody on the team wrote | Yes, often larger |
| Testing and edge cases | Written alongside the code | Must be checked independently of the agent | Yes |
| Integration and deployment | Unchanged | Unchanged, with more changes arriving | Yes |
| Uncertainty and risk | Unknown dependencies, unclear rules | The same, plus the agent's blind spots | Yes, unchanged |
Kollabe, a vendor of planning poker software, makes the same recommendation in a February 2026 post: estimate total delivery effort, not just coding time. The idea predates AI, since our comparison of story points and person-days already explains why points cover more than hours at a keyboard.
In practice, a story the team used to call a 5 because of its code volume may now be a 2. A story that touches a fragile service, a payment flow or a security rule may stay a 5 or even grow, because verifying generated code there is harder than writing it by hand.
How do you recalibrate story points for AI-assisted work?
Recalibration is a team decision, made once and then revisited, not a silent drift.
- Choose new reference stories. Pick two or three stories recently delivered with AI assistance, agree on their size together and use them as the new baseline for relative estimation.
- Mark the break in your history. Do not re-estimate past sprints. Note the sprint where the new references started, and read sprint velocity before and after that line as two different series.
- Ask what is left for humans. During Planning Poker, the Scrum Master can ask before each vote: what will we have to specify, review, test and integrate ourselves?
- Vote first, consult the AI second. If an assistant proposes an estimate, show it only after the first round of cards. Displayed earlier, it acts as an anchor, as explained in our article on anchoring bias.
- Observe for a few sprints. Tag stories where an agent wrote most of the code and compare their estimates with how they actually went. Discuss the gaps in the retrospective.
- Keep agent-only tasks apart. If some tasks are fully delegated to an agent with only a quick check, do not point them like human work. Track them separately, with a time box or a cost budget.
One rule applies throughout: do not paste confidential tickets, customer data or source code into an AI assistant that your company has not approved.
Should you drop story points altogether?
Sometimes, yes. The answer depends on how your team works, not on the presence of AI.
- Drop them if your stories are already sliced small and similar in size. Counting delivered stories and tracking cycle time, as Jeffries suggests, gives a forecast that is just as good with less ceremony.
- Keep them if story size varies a lot, if risks are hard to see, or if the team regularly discovers late that a "simple" story was not. The value of Planning Poker is not the number but the moment when two people reveal very different cards and explain why.
That moment is common. Our usage data shows how often first votes disagree on the stories estimated with Planning Poker Online. With AI in the loop, those disagreements tend to be about review effort, test coverage or the agent's limits, which is exactly what the team needs to discuss before committing.
What should not change is the order: the team votes independently, then the discussion happens, and only then can a tool or an assistant contribute a second opinion. Planning Poker Online has no AI feature: votes stay secret until the reveal, and nothing you type is sent to an AI model.
Frequently asked questions
Should AI agents get their own story points? AI agents should generally not get their own story points, because points describe the effort and uncertainty a team takes on. When an agent does most of the work, estimate the human part: specifying, reviewing, testing and integrating. Tasks delegated entirely to an agent are better tracked separately, with a time box or a cost budget.
Why does velocity increase with AI coding tools? Velocity increases with AI coding tools when a team keeps its old reference stories while agents draft the code faster. The same story keeps its old size but takes less time, so more points fit into a sprint. Recalibrating the reference stories and marking the break in the velocity history keeps forecasts meaningful.
Are story points still useful for forecasting with AI? Story points remain useful for forecasting with AI once the team has recalibrated its reference stories and gathered a few sprints of new data. Until then, forecasts should use wider ranges. Research such as the METR study shows that perceived speed gains can be wrong, so forecasts must rely on completed stories.
Can AI estimate story points instead of the team? AI cannot replace the team in estimating story points, because it does not know the team's context, its technical debt or the people available. An assistant can prepare a story or offer a second opinion after the first vote. The estimate itself should remain an independent team decision made during Planning Poker.
Sources
- Joel Becker, Nate Rush, Beth Barnes and David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, July 2025
- METR, We are Changing our Developer Productivity Experiment Design, February 2026
- Google Cloud, Announcing the 2025 DORA Report, September 2025, and DORA, State of AI-assisted Software Development 2025
- Scrum.org, From Velocity to "Agent Efficiency": Evidence-Based Management for the AI Era, January 2026
- Daniel Vaughan, Adapting Agile Ceremonies for AI Coding Agents: Sprint Planning, Standups, and Retros, April 2026
- Ron Jeffries, Story Points Revisited, 2019
- Matt Lewandowski, AI agents in your sprint: how copilots are changing what a story point means, Kollabe (vendor), February 2026
Estimate the work that is left
Agents change who writes the code, not the need to agree on what a story really involves. Create a free Planning Poker session: every vote stays hidden until the reveal, so the team's estimate comes before any machine's opinion. No sign-up required.
