If you’ve been around Agile teams for a while, you’ve probably noticed that velocity tends to draw a bit too much attention. People use it like a compass to figure out how fast a team is moving. It makes sense on the surface—velocity represents the number of story points completed in a sprint, so higher numbers should mean better performance, right? But here’s where that line of thinking starts to wobble. Velocity might be a reflection of how much work a team is finishing, but it is not how you measure performance. This distinction is key, and the moment we forget it, things can go off the rails pretty quickly.
I’ve seen it too often: stakeholders or team leads begin using velocity as a yardstick for team success. As soon as that happens, the team’s focus quietly shifts from doing high-quality, impactful work to hitting some arbitrary number. And guess what? You’ve just dug yourself a hole, because when velocity becomes the target, that’s when velocity itself risks being manipulated. This is what’s known as Goodhart’s Law, and it’s common enough that I joke every team should have a “Keep Goodhart at bay” poster hanging up somewhere.
What does manipulation of velocity look like? It can sneak in through inflated estimates. Teams realize that by assigning slightly higher point values to user stories, they can inflate their velocity without necessarily doing more work. It’s not dishonesty; it’s just human nature kicking in. No one wants to look like they’re falling behind. When there’s a pressure to increase velocity, teams may unconsciously (or even consciously) inflate estimates to keep up appearances. Rather than reflecting an honest assessment of effort, velocity soon tells the story of a team trying to meet a number, not deliver value.
This is where we start treading into dangerous territory. If stakeholders—especially those outside the team—begin using velocity to gauge how “productive” the team is, you’ve essentially set up a perverse incentive. Instead of asking, “What valuable work did we deliver?” the conversation shifts to, “How many points did we close out this sprint?” These are vastly different questions, and responding to the wrong one can lead to bad outcomes, both for the product and the team’s morale.
When velocity becomes a target instead of a measure, and that number is what the team or stakeholders start to chase, something else quietly slips out of focus: performance. True performance goes beyond how many story points you complete in a sprint. It’s about delivering working software that solves real problems and creates value for the users. There’s no point in boasting about hitting your velocity target if what you’re delivering doesn’t function well or needs to be reworked two sprints later due to quality issues.
The tricky part here lies in that subtle shift in thinking. The team may unconsciously deprioritize essential, behind-the-scenes work—like proper testing or refactoring—just to close more stories on the board. And once that becomes the pattern, the team’s effectiveness starts to erode. Quality takes a back seat, and over time, the technical debt keeps piling up. What started as a sprint or two of “hitting velocity” transforms into a product that becomes harder and harder to enhance or maintain. That’s a slippery slope Agile coaches are always trying to help teams avoid.
Then there’s the issue of stakeholder perception. When people outside the team start looking at velocity as a benchmark for how “productive” the team is, they might begin asking why velocity isn’t going up every sprint. Some might even push for it to be a performance goal: “We expect the team to hit 60 story points next sprint.” Suddenly, you’ve dragged what should be a reflection of the team’s capacity through the mud, turning it into a race. At this point, you’re no longer focusing on real outcomes—you’re stuck trying to maintain an arbitrary number. Here’s the thing: every team’s velocity is going to fluctuate. Work complexity changes, people go on vacation, unexpected bugs pop up—it’s normal. Expecting velocity to climb continuously is unrealistic and unhealthy for the team’s morale.
This isn’t to say velocity is useless—it’s a helpful tool, but it’s meant for internal use. Velocity helps the team gauge how much work they can take on in the upcoming sprints, giving them a sense of their own capacity. But it should never be a stick to judge performance.
The better approach is to look at outcomes over output. Is the team delivering valuable features to users? Are the customers satisfied with what’s being released? How is the quality of the work being measured? These are far more meaningful ways to evaluate how well the team is doing. After all, Agile is all about continuous improvement and delivering value. If that’s not driving decisions, the process needs a closer look.
If you really want useful metrics, consider looking at things like cycle time—how long it takes for a piece of work to go from “start” to “done”—or lead time, which measures the overall time from when an item is added to the backlog to when it’s delivered. These metrics offer a clearer picture of the team’s efficiency and flow without pushing the team to focus on points for the sake of points. Asking the team during retrospectives about bottlenecks, blockers, or areas where they need support is far more valuable in helping the team improve than chasing velocity.
Ultimately, the focus should be on the quality of the product and whether it meets user needs. Performance is about answering the question, “Are we delivering what the business and users need, and can the product hold up in production?” If your velocity is improving but teams are putting out high-bug, low-value work, you’re not winning any victories.
So, when the urge to use velocity as a performance metric creeps in, remind yourself and your stakeholders: it’s a guide to capacity, not a scoreboard. Teams deliver value. That’s what should drive every conversation.
#AgileMetrics #MeasuringPerformance #ScrumPractices #TeamEffectiveness