Is Your Team’s Velocity a Weapon? Why We Need to Stop the Scrum Comparison Game

In my experience working with different Scrum teams, one thing that keeps popping up is how we talk about and use velocity. For those who might be newer to Scrum, velocity is basically the amount of work a team manages to get done in a sprint. It’s usually measured in story points or some other unit the team agrees on.

Now, I’ve seen velocity used in some interesting ways, and honestly, sometimes it makes me a little uneasy. It feels like there’s a temptation to look at one team’s velocity compared to another, or even to track individual contributions based on how many points they “deliver.” And from what I’ve seen, that can lead down a tricky path.

What I’ve Noticed About Velocity

For the teams I’ve been a part of, velocity seems most helpful when we’re just trying to figure out how much we can realistically take on in the next sprint. It gives us a rough idea based on what we’ve done in the past. But it’s just an average, right? Some sprints are smoother than others; some stories are way more complicated than they initially seem.

Why Comparing Feels Off

• Every Team is Different: The way one team estimates might be totally different from another. Their team dynamics, their skill sets, even the complexity of the problems they’re solving can vary wildly. So, comparing their velocity numbers feels like comparing apples and oranges.
• It Can Mess with Team Spirit: When the focus shifts to “beating” another team’s velocity, or even just increasing our own number at all costs, it can take away from the real goal: working together to deliver something valuable. I’ve seen it create unnecessary pressure and even make people hesitant to ask for help.
• Complexity Isn’t Always Reflected: A “5-point story” for one team might involve a whole lot more headaches and hidden work than a “5-point story” for another. Just looking at the points doesn’t always tell the full story (pun intended!).
• The Real Win is Value: At the end of the day, what really matters is whether we’re delivering something that users love and that meets the business needs. A team with a slightly lower velocity that consistently delivers high-quality, valuable features is, in my opinion, way more successful than a team chasing a high number but not delivering the right things.

How I Think Velocity Could Be More Useful

1. For the Team, By the Team: It feels like velocity is most useful when the team uses it for their own planning and to see their own trends over time. Are we consistently underestimating? Are there things slowing us down?
2. Looking at Trends, Not Just Numbers: Instead of getting hung up on the specific velocity of one sprint, maybe it’s more helpful to look at the overall trend. Are we generally improving? Are there dips we need to understand?
3. Focusing on What Matters: I think we should celebrate when we deliver something awesome, regardless of the exact velocity number. The real win is happy users and a product that’s making a difference.

My Takeaway

From what I’ve seen, velocity is a tool, and like any tool, it can be used in helpful or not-so-helpful ways. For me, it feels like its main purpose should be to help the team plan better, not to create competition or judge performance. Let’s focus on building great products and supporting our teams in the best way possible.

What are your thoughts? Have you seen similar things in your experience? I’d love to hear your perspective!