Ah, velocity. The cherished metric of software teams everywhere; or at least by the managers who love charts and graphs with upward trajectories. For those unfamiliar, velocity is the measure of how many story points a team delivers in a Sprint. And while it sounds useful, in my experience, it’s one of the most misunderstood and misused concepts.
So, let’s dig in. Is velocity the holy grail of team productivity, or is it the illusion of control dressed up as a metric? Spoiler: it’s the latter.
The Story Points Illusion
At its core, story points are a relative measure of effort, complexity and risk. They make sense within a team. Emphasis on within. Team A’s story points are not comparable to Team B’s, and even within Team A, story points are just a tool to facilitate discussions. Yet somehow, people outside the team love to treat them like absolute truths.
Enter the dreaded question: “Why is our velocity lower this Sprint?”
Here’s the thing - story points are not deadlines. They’re not commitments. They’re not progress indicators. They’re simply a way for a team to collectively understand the complexity of their work. However, when managers start equating velocity with productivity, it quickly devolves into nonsense metrics that drive unhealthy behaviors.
When Velocity Becomes a Problem
1. The Illusion of Control
Velocity gives some managers the illusion that they’re in control. By tracking the “number” of story points delivered, they think they’re driving efficiency. But here’s the truth: asking “Why is velocity down?” doesn’t magically solve user problems. It just pressures the team to inflate numbers or sacrifice quality to hit an arbitrary target.
2. Unhealthy Comparisons
“Team B is delivering 100 story points per Sprint; why are we only doing 60?”
This question is the equivalent of comparing apples to oranges. Different teams, different contexts, different baselines. It’s not only unproductive; it undermines team morale.
3. Missing the Bigger Picture
Focusing on velocity distracts teams from what actually matters: solving user problems and delivering outcomes. The goal isn’t to deliver the most story points. It’s to deliver the most value.
What Story Points Are Actually Good For
Let’s be fair: story points aren’t inherently bad. They serve one valuable purpose - building a shared understanding.
When a team estimates a story, it forces them to discuss complexities, dependencies, and potential risks. That’s the real value. It’s not about whether a task is a “3” or a “5.” It’s about the conversation that happens when someone says, “Wait, why do you think this is a 13? Did we miss something?”
Story points drive collaboration. They help teams align on what needs to be done and how difficult it will be. But beyond that? The actual number doesn’t matter.
Stop Obsessing over Velocity and Start Measuring Outcomes
The most productive teams don’t obsess over how many story points they’ve delivered. Instead, they focus on the outcomes they’re driving.
Here’s what that looks like:
Instead of asking: “What’s our velocity this Sprint?”
Ask: “Did we achieve our Sprint Goal? Did we move closer to solving our user’s problem?”
The best metrics aren’t about how many tasks you’ve completed. They’re about the value you’ve delivered. For example:
Did we reduce user churn by X%?
Did we speed up onboarding by Y minutes?
Did we address a critical user pain point?
Velocity is about output. Outcomes are about impact. Choose wisely.
The Role of Leadership in Fixing This
If you’re in a leadership role and you’re still using velocity as your north star, it’s time to rethink. Your job isn’t to push the team to deliver more points, it’s to create an environment where the team can deliver meaningful results. That means:
Trusting your team’s expertise. They’re closest to the ground. Let them define how to get there.
Setting clear goals. Help the team focus on outcomes, not tasks.
Removing obstacles. Whether it’s endless meetings or unclear priorities, your role is to clear the path for your team to thrive.
And most importantly, stop asking why velocity is low. Start asking how you can help the team achieve their goals.
A Real-World Example
Eons ago, I worked with a team that consistently delivered “low velocity” compared to others in the organization. On paper, it looked bad. But here’s the thing: they were solving big, hairy problems that had gone unaddressed for years. Their work directly reduced customer churn, improved retention metrics, and created new revenue streams.
Meanwhile, another team with “high velocity” was churning out low-impact features no one asked for. Guess which team added more value to the company?
Where Do We Go From Here?
If we want to build better teams and better software, we need to stop obsessing over how many story points we can cram into a Sprint. Instead, we need to:
Focus on meaningful goals. Set Sprint Goals that solve real problems.
Measure what matters. Define metrics that reflect user impact, not task completion.
Use story points for alignment. Not as a scoreboard.
Velocity isn’t inherently evil, but it’s not a measure of success either. If we keep treating it like one, we’ll miss the forest for the trees. So let’s stop caring about how fast we’re moving and start caring about where we’re going.
Because in the end, the goal isn’t just to move fast. It’s to move forward in the right direction.
Who still cares? Well: I still care! But only for teams who don't have bigger problems. Velocity doesn't solve problems. Measuring it usually doesn't either. Once you've got the biggest problems outta the way, teams can (and should) focus on improving predictability on a bigger scale. That's what velocity and story points are for. Here's my take on the topic:
https://robertkalweit.com/en/2021/07/05/how-to-not-get-burnt-an-abbreviated-story-about-agile-estimation/