Key Points
- Story points and velocity were built on an assumption: that the effort to draft a solution roughly tracked the effort to deliver it. AI is breaking that link by collapsing drafting effort toward zero while leaving verification effort largely where it was.
- A team whose velocity jumps from 50 to 5,000 in a sprint hasn't gotten 100x better. It's produced a number that no longer measures the thing anyone cares about, and more engineering leaders are quietly admitting this every quarter.
- What's replacing velocity isn't a single metric. It's a shift toward outcome-oriented measures: defect density in AI-generated code, rework percentage, lead time to value, and issue resolution time, none of which can be inflated just by generating more draft code faster.
- Why the Man-Month Is Dying: How AI Broke IT Services' Oldest Pricing Unit covered why the man-month is dying as a pricing unit. This one covers the parallel death of story points as a delivery-measurement unit. The two are breaking for the same underlying reason, on different sides of the same contract.
Introduction
A client-side engineering director told me recently that her team's velocity chart looked like a hockey stick after they rolled out agentic coding tools, and that she'd stopped showing it to her own leadership because it made her look like either a liar or an idiot. Neither was true. Her team had actually improved. The chart just couldn't say by how much, or at what, because the number it produced no longer meant what it used to mean.
Story points measure estimated effort, and velocity is story points delivered per sprint, a proxy that worked reasonably well as long as the bottleneck in software delivery was drafting: writing the code, wiring up the boilerplate, working through the mechanical parts of a ticket. AI-assisted development attacks exactly that bottleneck and leaves the other one, verification, largely untouched. When drafting effort collapses toward zero and verification effort doesn't move much, a velocity number built on the old ratio between the two stops correlating with anything real. Scrum.org's own framing of the problem is blunt: if a team's velocity jumps from 50 to 5,000 in a single sprint, they haven't gotten 100x better. They've broken the metric, because it was always a proxy for effort, and AI reduces the drafting effort to near-zero while leaving verification complexity high.
The industry data backs up how fast this is becoming unignorable. Teams running agentic AI tools report 10-20x velocity gains alongside 40-78% fewer bugs, numbers that sound like unambiguous good news until you try to use them for the same planning and comparison purposes velocity was always used for. You cannot forecast a roadmap, compare two teams, or set a hiring plan against a metric that swings by two orders of magnitude depending on which AI tool got rolled out last quarter. Teams that haven't found a replacement are flying blind with better instruments than they've ever had, which is its own kind of dangerous.
Old Velocity Metrics vs. Post-AI Delivery Metrics
| Criteria | Story Points / Velocity | Post-AI Delivery Metrics |
|---|---|---|
| What it actually measures | Estimated drafting effort per sprint | Defect density, rework rate, lead time to value, issue resolution time |
| Inflatable by AI tooling alone | Yes, trivially, without any real gain | No, each metric requires an actual outcome to move |
| Useful for cross-team comparison | Only if both teams use identical tooling and estimation habits | Yes, outcomes are tooling-agnostic |
| Useful for client-facing reporting | Increasingly not, since AI adoption accelerated in 2026 | Yes, clients can verify a defect rate or a resolution time against their own experience |
| What a spike in the number tells you | Nothing reliable | That verification-adjusted output actually improved |
Recommendation: if your organization is still running sprint retros around a velocity chart, check whether anyone on the team can explain what a 10x jump in that number would actually mean. If the honest answer is "the tooling changed," the metric isn't tracking delivery anymore. It's tracking tool adoption, and you should be measuring that separately from outcome quality.
Where This Is Likely Headed
- Right now: denial and dashboards for most teams. Most teams are keeping the velocity chart because the tooling to replace it (defect-density tracking, rework attribution, lead-time-to-value instrumentation) isn't built yet, and nobody wants to be first to admit their headline metric is cosmetic.
- Expect a credibility break within the next year or two. As more teams get publicly embarrassed by an unexplainable 50-to-5,000 velocity swing, engineering leadership will stop defending the metric in front of executives and clients. "Agent efficiency" language is already starting to replace "velocity" in serious planning conversations.
- Outcome metrics should go from experimental to standard within a few years. Rework percentage and AI-attributed defect rate are becoming normal line items on engineering dashboards, not because they're perfect, but because they can't be gamed by pointing an agent at a backlog overnight.
- The end state: metrics become a client-facing artifact, not just an internal one. Firms moving toward outcome-based contracts are starting to share rework and defect data directly with clients, because the metric is finally honest enough to survive that exposure.
Questions to Ask Your Team
- If our velocity doubled next sprint, could anyone on this team explain exactly why, in terms a client would find credible?
- Are we tracking rework and defect rate on AI-generated code specifically, or lumping it in with everything else and losing the signal?
- Would we be comfortable sharing our current delivery metrics directly with a client, or are they really an internal-only number dressed up as evidence of progress?
- Is any part of a team's evaluation or bonus still tied to raw velocity, in a way that quietly rewards inflating a number everyone privately agrees is broken?
Conclusion
Story points and velocity aren't failing because someone calculated them wrong. They're failing because the thing they measured, effort, is no longer correlating with the thing everyone actually wanted to know, which was progress. The teams adapting fastest aren't the ones with the flashiest AI tooling. They're the ones willing to admit their dashboard is lying to them and replace it with metrics, defect density, rework rate, lead time to value, that can't be inflated by the same tools that broke the old ones. The man-month is dying on the pricing side of the contract. Velocity is dying on the delivery side. Neither death is really about AI being too good. It's about a proxy finally getting exposed as a proxy.
Further Reading
- Scrum.org: From Velocity to "Agent Efficiency", Evidence-Based Management for the AI Era
- Oobeya: Engineering Metrics in the AI Era, A Complete Guide for 2026
- GitVelocity: AI Broke Your Engineering Metrics. Here's What Works Now
If this helped, a like and a follow are appreciated — and if you've solved this differently, drop a comment, I'd like to hear it.
Bry Writes Code; cloud and AI infrastructure specialist. Still reporting velocity to a client and not sure it means anything anymore? Let's talk.
Top comments (1)
The verification point is where old velocity really breaks for me. If AI makes drafting cheap but review, test design, and rollback risk stay scarce, points start measuring text generation rather than delivery capacity. I would rather see teams track rework and escaped defects per AI-assisted change.