Why the Answer to AI-Driven Story Point Deflation Isn't Kanban
The Story Point Paradox
Story points are coming apart.
With AI in the loop, what used to be an 8-point task might now be a well-crafted prompt. Teams are quietly downgrading estimates — because why wouldn't you, when half the work disappears into a chat window? The same sprint that used to burn 40 points now clocks 40 points, except each point represents far less complexity. That's story point deflation: the unit loses its purchasing power.
Other teams resist re-estimating and let the numbers run. Their velocity charts spike as more work gets done in the same time — story point inflation. Same endpoint, different path: the numbers stop meaning what they used to mean.
Either way, story points were never about timeliness to begin with. They were a relative-effort heuristic. Yet in practice, they became the single number everyone looked at. Velocity charts turned into dashboard candy. More points meant a better sprint.
Output Is Not Outcome
The more productive we get, the more obvious the fraud becomes. A sprint that burns 80 story points feels more successful than one that burns 30 — even if the 30-point sprint was the one that actually moved a metric. Velocity was always a measure of output, not outcome.
PMs chasing point totals are optimizing for the wrong thing, and AI is putting that liability in sharp relief. If everything is fast, speed ceases to be a differentiator. The bottleneck shifts from execution to decision-making.
Why Kanban Is Not the Answer
The obvious reflex is to abandon scrum altogether and move to kanban — continuous flow, no points, no sprints. WIP limits and cycle time don't answer the fundamental question either. They still measure throughput, just with different units. You can't out-process a broken feedback loop.
Meanwhile, PMs are already using AI to write, refine, and augment tickets. AI is not just accelerating code — it's reshaping the entire SDLC, from ideation to deployment. The tools are changing. The workflow must follow.
Give AI Better Context
The real shift is feeding AI something better than story points and ticket titles: the hypotheses behind the work. What assumption are we testing? What metric do we expect to move? What would make us stop?
This isn't a new idea. Product discovery has been mapping opportunity space against solution space for years, running validation experiments to loosen the grip of "what" and sharpen the "why."
Hypothesis-driven development formalizes that instinct: each work item becomes a structured bet with explicit intent, assumptions, and success criteria. That's exactly the context AI needs to move from supercharged code generator to genuine reasoning partner.
When every sprint item carries a testable hypothesis, the process stops being about how much we shipped and starts being about what we learned. Software development becomes knowledge exploration, not a continuous flow of productivity.
The core challenge with enhanced productivity is not how to do more — that is solved. It's finally finding what to do at all.
Scrum and kanban were never about great ideas — they were about execution throughput, because that was the bottleneck. As AI dissolves that bottleneck, direction becomes everything. It's time to invest in the why instead of measuring the what.
If you're a PM asking whether kanban is now the better fit — hopefully this post encouraged you to ask the larger questions instead. The task board is already being reshaped by AI, whether we like it or not. Our bet: its primary unit won't be work completed. It will be assumptions tested, evidence gathered, and decisions changed. That's a different game entirely. And that's the one worth playing.