By Priya Shankar
Your sprint velocity is climbing. Every two weeks, the team completes more points. The burndown chart looks beautiful. Leadership sees the graph trending up and nods approvingly. Meanwhile, the codebase is rotting.
This is the quiet disaster happening in most engineering organizations. Velocity becomes the enemy of speed.
The mechanics are simple. When you measure sprint velocity, teams optimize to make the metric go up. That means taking smaller tickets. Avoiding refactoring work. Cutting corners where the code is already messy because refactoring shows up as rework and drags the velocity down. By Q3, the team has completed 40% more story points than they did in Q1. By Q4, they are half as fast as they were in Q1.
I've watched this cycle at three different companies. It always looks the same. The breakdown is invisible until it is catastrophic. A feature that would have taken two sprints in month two takes eight sprints in month eighteen. The team looks lazy. The team looks entitled. The team is neither. The team is moving through a codebase that has been optimized for metrics, not for change.
The perverse incentive is baked into the metric itself. Velocity measures throughput. It does not measure quality, maintainability, or architectural coherence. So teams rationally choose to defer anything that reduces velocity in the short term but preserves it in the long term. They defer refactoring. They defer paying down technical debt. They defer the structural work that would let them move faster next sprint because it would make them slower this sprint.
Then the metric goes up, and the organization celebrates.
Engineers see this. They feel it. They watch the codebase they care about get worse while the org watches the velocity chart get better. That gap between the chart and reality creates a particular kind of despair. The metric is supposed to measure health. Instead, it is measuring decline. And the faster the metric climbs, the worse the problem becomes.
The velocity spike is a lie detector for codebase rot. When velocity starts climbing without a corresponding increase in team size or senior hiring, something is wrong. The team is eating its own future to satisfy today's sprint goals.
So what should you track instead?
First: codebase health trending in your high-touch modules. Not a generalized health score. Specificity matters. You want to know which parts of your codebase are getting more fragile, more tightly coupled, harder to change. The modules that every new feature has to touch are the ones that matter most. If your authentication layer or your data pipeline or your API contract layer is accumulating debt, you feel it immediately across everything else. That is the signal. Tools like Glue show you exactly which modules are where, how they are changing week to week, which ones have become bottlenecks. That tells you where the rot is happening, and it tells you early, before it has compounded into eighteen months of slowdown.
Second: cycle time on features that touch your debt-heavy areas. Velocity is meaningless if you do not know the composition of the work. A sprint with twenty points of feature work looks identical to a sprint with five points of feature work and fifteen points of refactoring and technical debt paydown. But the organization's runway is completely different. If your high-risk modules have three-week cycle times instead of three-day cycle times, that tells you that the architecture is constraining you. That is not a team problem. That is a design problem. And it is fixable, but only if you measure it.
Third: unplanned work ratio. This one is harder to game. If your team is spending more than thirty percent of their capacity on unplanned work—bugs, incidents, urgent production fixes, the work that shows up because the codebase is fragile—then you are not in a sustainable state. You are insolvent. You are spending more than you have. Thirty percent is the line. If you cross it, your sprint goals are fiction. Your velocity is theater. Your team is in reactive mode and will stay there until you pay down the technical debt enough to get the unplanned work ratio back below the line. Glue shows you this too: which modules generate the most support requests, which parts of the codebase cause the most urgent production work.
These three metrics do not look as clean as velocity. They do not produce a beautiful graph with a line trending up and to the right. They tell you the truth instead of a story.
The teams that move fast long-term are not the teams with the highest velocity. They are the teams that stayed thoughtful about their codebase. They are the teams that knew exactly where their technical debt was, which modules were slowing them down, and had the organizational permission to slow down in the short term to speed up in the long term. They kept their cycle times low on the modules that matter most. They kept their unplanned work ratio below the line.
Your velocity metric is not evil. It is just incomplete. Velocity alone is not enough to see what is actually happening. You need to see what is underneath the velocity. And that means seeing the codebase itself, which modules are becoming harder to change, which areas are slowing down every sprint, which parts of the system are generating the most unplanned work.
Stop celebrating velocity. Start tracking reality. The codebase will thank you.
Frequently Asked Questions
If we stop measuring velocity, how do we know if the team is productive? Productivity is not the same thing as throughput. A team that delivers fewer story points but keeps the codebase healthy and maintains cycle times under three days on critical paths is more productive than a team that delivers more points while adding debt. You need metrics that capture both speed and sustainability. Cycle time on your highest-impact modules and unplanned work ratio do that. Velocity alone does not.
Isn't some refactoring and debt paydown already baked into our velocity estimates? In theory, yes. In practice, almost never. When a team estimates a feature at five points, that is the estimate for the feature itself. The refactoring that the feature requires, the module that becomes more fragile after the feature, the technical debt that accumulates—that is invisible in the estimate. It shows up later, in months two through eighteen, as slower cycle times and higher unplanned work. That is why module-level health tracking is so important. It makes the invisible visible.
Can we just train teams better to include refactoring in their estimates? You can try. But the incentive structure is working against you. If refactoring is estimated as "rework," it lowers velocity. If it is estimated as part of the feature, the feature estimate becomes unpredictable and bigger. Most teams will choose the path that looks cleaner on the chart. The solution is not training. It is changing what you measure.