Metrics & Planning
Velocity, Estimation, and Metrics When AI Accelerates Output
AI tools change the relationship between effort and output. Here's how to make sprint planning and velocity tracking meaningful when AI is doing part of the work.
The Velocity Problem
Velocity is a measure of how much work a team completes in a sprint, expressed in story points. It's used to forecast how much a team can commit to in future sprints. It is an input to planning, not a performance metric.
AI-assisted development breaks the underlying assumption behind velocity: that story points represent a relatively stable amount of human effort. When a developer who used to take 8 hours to implement a feature now takes 3 hours because of AI tooling, velocity increases — but capacity hasn't.
What this means practically:
- Velocity from pre-AI development history is not a reliable baseline for AI-assisted sprints.
- Velocity will appear to increase significantly in the first several AI-assisted sprints, then stabilize as teams absorb more complex work into their capacity.
- Comparing velocity across teams where AI tool adoption differs is misleading.
Reframing What to Measure
The Scrum Master's job here is not to fix velocity — it's to help the team understand what their metrics actually measure and what decisions those metrics should inform.
Outcome metrics worth tracking alongside velocity:
| Metric | What it Measures |
|---|---|
| Cycle time | How long a story takes from "in progress" to "done." AI typically reduces this. |
| Escaped defects per sprint | How many bugs found in production from sprint deliverables. AI code generation can increase this if review standards don't keep up. |
| Rework rate | What percentage of sprint stories required significant rework after initial completion? |
| AI review coverage | What percentage of AI-contributed code received human review? |
| Team confidence score | A simple 1-5 survey asking "how confident are you in what we shipped this sprint?" |
None of these replace velocity for planning purposes. They complement it by telling a richer story about quality and sustainability.
Estimation in an AI-Assisted Environment
Story point inflation: When a story that used to take 5 points now takes 2 points with AI, should the story be re-estimated at 2 points?
The answer depends on what your team uses story points for. If points represent complexity (not time), the story's complexity didn't change — only the effort to resolve that complexity did. In this framing, re-estimation is wrong.
If your team uses story points as a proxy for time (as most teams do in practice), re-estimation makes sense, but it means your historical velocity is no longer comparable. Document the transition point.
A practical approach: Introduce a separate "AI assistance factor" annotation on stories. Stories where AI contributed significantly (more than 50% of code) get a flag. Track velocity for flagged and unflagged stories separately for four to six sprints. This gives you a calibrated picture of what your team can commit to in AI-heavy sprints versus mixed sprints.
The Sprint Commitment Conversation
The most important planning conversation for AI-assisted teams is about risk, not velocity. When AI tools are contributing significantly to a sprint, two risk categories increase:
Technical debt risk: AI-generated code that was reviewed quickly tends to accumulate architectural debt faster than carefully-considered human-written code. Stories may close faster but re-open as other stories hit the same code.
Integration risk: When multiple developers are using AI tools in parallel, integration points surface later and hit harder. Sprint planning needs more explicit attention to integration stories as their own workstream.
The Scrum Master surfaces these risks in planning, not to slow the team down, but to ensure the sprint commitment is honest.
Communicating Metrics to Stakeholders
Stakeholders watching velocity increase as AI tools are adopted may draw incorrect conclusions: "the team is working harder," "let's add more stories," or "we can reduce headcount."
The Scrum Master is not the right person to have the stakeholder conversation about AI's impact on capacity — that's the Product Owner's territory. But the Scrum Master can equip the Product Owner with the right framing:
- AI tools increase throughput for certain story types, not all story types.
- Code output speed and product quality are not the same variable.
- Sustainable velocity requires ongoing investment in code health, test quality, and team skills — investments that don't show up immediately in sprint velocity.