Velocity made sense when output was scarce.
Writing code was expensive. Teams had limited capacity. Measuring how much got done told you something about team effectiveness.
AI changed that. Now you can generate unlimited output. Velocity became meaningless. You could hit any velocity number by just generating more code.
The scarcity moved. Understanding is now what's scarce. Can the team comprehend what they're building? Can they maintain it? Can they change it safely?
Measure that instead.
Why Velocity Became Noise
Velocity = story points completed per sprint.
When AI can generate story points worth of code in minutes, velocity decouples from effort. It decouples from difficulty. It decouples from value.
High velocity might mean: - The team is productive - The team is generating code nobody understands - Story points are undersized - AI handled most of the work
Low velocity might mean: - The team is struggling - The team is being thoughtful about quality - Story points are oversized - The team is documenting and preserving context
Velocity no longer tells you which interpretation is correct.
Understanding Metrics
What would it mean to measure understanding?
**Explanation test.** Can team members explain how parts of the system work? Pick a component. Ask someone who didn't build it to explain it. Track accuracy.
**Prediction test.** Before making a change, predict what will happen. After the change, compare prediction to reality. Track accuracy over time.
**Onboarding time.** How long until new team members can contribute meaningfully? If this increases, understanding isn't being preserved.
**Decision coverage.** What percentage of significant decisions are documented with rationale? Low coverage means context is evaporating.
**Maintenance cost.** How much effort goes into fixing unexpected problems? High maintenance suggests gaps in understanding.
These are harder to measure than velocity. That's why teams default to velocity. But hard to measure doesn't mean unimportant.
The Transition
You probably can't drop velocity immediately. Stakeholders expect it. Tools report it.
Start by adding understanding metrics: - Pick one or two - Measure alongside velocity - Note when they diverge
When velocity is high but understanding is low, you're generating code nobody comprehends. That's not progress. That's future pain.
When understanding is high, you have a team that can maintain and evolve what they've built. That's durable progress.
Over time, de-emphasize velocity. Emphasize understanding. The metrics you track shape behavior. Track what matters.
The Goal
The goal isn't high velocity. The goal is building something that works, that can be maintained, that can evolve.
High velocity with low understanding creates fragile systems and mounting technical debt.
Moderate velocity with high understanding creates sustainable systems and compounding capability.
Measure what matters. Understanding matters more than output now. Measure it.