Dont Compare Team Velocities

Close

Don’t compare team velocities.

It’s tempting. I understand why leaders do it.

One team completes 42 points in a sprint. Another completes 27. A third completes 63. Put those numbers in a chart and it looks like you have a simple way to compare teams.

You don’t.

Velocity is useful. It can help a team forecast how much work it may complete in the future. It can help a Product Owner think about what might fit before a date. It can help a team notice when something has changed.

But velocity is useful mostly inside one team.

It is not a good way to compare teams.

When leaders compare velocities, the numbers start to lie. Teams learn what is being watched, and they respond. Not because they are dishonest. Because they are human.

If velocity becomes the target, teams will get better at velocity.

That does not mean they will get better at delivering value.

What Velocity Is Supposed to Do

Velocity is a measure of how much work a team finishes in a sprint or iteration.

Most agile teams estimate product backlog items. Many use story points. At the end of a sprint, the team adds up the points for the items it actually finished. That total is the team’s velocity.

If a team finishes five product backlog items estimated at 3, 5, 5, 8, and 13 points, its velocity for that sprint is 34.

That number can be useful.

If the same team has finished around 30 to 40 points in recent sprints, the Product Owner and team can use that information to forecast. If there are five sprints before a release, the team might reasonably expect to finish somewhere around 150 to 200 points, assuming nothing significant changes.

That is a good use of velocity.

The team is using its own history to make a reasonable forecast about its own future.

Problems start when leaders take velocity outside the team and use it to compare teams.

Why Comparing Velocities Does Not Work

Story points are not a universal unit of measure.

They are not inches, pounds, dollars, or hours. They are not standardized across teams. One team’s five-point item is not necessarily the same size as another team’s five-point item.

A team estimates by comparing one product backlog item to another. They might decide that one item is twice as much effort as another. Another team might agree about the ratio but use different numbers.

One team may estimate two items as 5 and 10. Another team might estimate similar items as 3 and 6. Another might use 8 and 16.

The numbers are different, but the relationship is the same.

That is fine when the numbers are used inside the team. It becomes a problem when someone compares one team’s total with another team’s total.

A team with a velocity of 60 is not necessarily twice as fast as a team with a velocity of 30.

It may simply estimate differently.

The Teams Are Not Doing the Same Work

Even if story points were somehow standardized, comparing team velocities would still be misleading.

Teams work on different products, different codebases, different problems, and different types of risk.

One team may work in a clean, well-tested product. Another may work in an older system with years of technical debt. One team may have fast access to users and stakeholders. Another may wait days for decisions. One team may be interrupted constantly. Another may be protected. One team may have a strong Product Owner. Another may have three stakeholders fighting over priorities.

Those differences matter.

Velocity does not tell you whether a team is dealing with unclear requirements, fragile architecture, slow approvals, missing skills, production support interruptions, or dependencies on another group.

It only tells you what the team finished using the team’s own estimating scale.

That can be useful.

It just does not mean what many leaders want it to mean.

What Happens When Leaders Compare Velocities

Teams respond to what leaders measure.

If a leader publishes a chart comparing team velocities, the leader may not say, “The team with the highest velocity is best.” But people will hear it anyway.

A team with a lower velocity will wonder whether it looks bad. A team with a higher velocity may feel pressure to stay on top. Teams that were estimating honestly may begin, often subtly, to estimate differently.

A five-point story becomes eight.

An eight-point story becomes thirteen.

No one has to announce this. No one has to cheat. The pressure changes the conversation.

A team debating whether an item is five or eight points will start to remember that velocity is being compared. Eight begins to feel safer.

The team’s velocity goes up.

Nothing else improves.

That is estimate inflation.

The chart looks better, but the organization has learned less.

Velocity as a Target Creates Bad Behavior

The problem is not that teams are bad.

The problem is that the measurement is being used badly.

When velocity becomes a target, it stops being a useful measure.

Teams may inflate estimates. They may avoid story splitting because larger items can make the numbers look better. They may focus on finishing more points instead of delivering more value. They may become reluctant to take on important but uncertain work. They may spend more time explaining the number than improving the work.

The organization gets a cleaner chart and a worse conversation.

That is not leadership.

Agile leaders should want honest information. Comparing velocities makes honest information harder to get.

Velocity Can Still Be Useful

None of this means velocity is bad.

Velocity is useful when a team uses it for its own forecasting and improvement.

A team can look at its own velocity over time and ask what is happening. If velocity drops sharply, maybe the team is dealing with more interruptions. Maybe the work is less clear. Maybe technical debt is slowing them down. Maybe the team changed membership. Maybe testing is happening too late. Maybe the Product Owner is unavailable.

Those are useful conversations.

Velocity can also help a Product Owner and team forecast. If the team usually completes 30 to 40 points per sprint, it can make a more honest release forecast than if everyone simply guesses.

Velocity is a tool for learning.

It becomes a problem when leaders turn it into a ranking system.

What Leaders Should Do Instead

If you want to understand how a team is doing, spend time with the team.

Go to Sprint Reviews. Talk with the Product Owner. Ask what the team is learning. Look at the product. Ask what is slowing the team down. Ask what decisions the team needs. Ask what tradeoffs need to be made.

You can still use metrics. But use them carefully.

Customer satisfaction, defect trends, cycle time, release frequency, escaped defects, team morale, customer adoption, and business outcomes may all tell you something useful. No single measure tells the whole story.

The best leaders use a few measures together and then talk with people to understand what the measures mean.

A metric should start a conversation.

It should not replace one.

Better Questions to Ask

Instead of asking, “Why is Team A’s velocity lower than Team B’s?” ask a question that helps the team and organization learn.

Ask what is making the work harder than it needs to be.

Ask whether priorities are clear enough.

Ask whether the team has the skills it needs.

Ask whether the Product Owner is available.

Ask whether dependencies are slowing the team down.

Ask whether the team is getting useful feedback from stakeholders.

Ask whether the team is improving its ability to finish work.

Ask whether leaders are creating interruptions the team cannot control.

Those questions will teach you more than a velocity comparison ever will.

If You Need to Compare Something, Compare Outcomes

Leaders do need to understand performance.

They need to know whether teams are delivering value, improving quality, reducing risk, satisfying customers, and helping the business make progress.

Compare those things carefully.

A team building a new product, a team maintaining an old platform, and a team working on regulatory changes may not have the same outcome measures. That is OK. The point is not to create one perfect metric for every team.

The point is to look for evidence that each team is helping the organization achieve its goals.

Velocity is not that evidence.

Velocity is an input to a team’s forecasting conversation.

How to Talk About Velocity with Teams

Leaders do not need to ignore velocity.

They just need to talk about it the right way.

A good conversation sounds like this:

“Is your velocity useful for forecasting?”

“What has changed recently that might affect your forecast?”

“Are you using a range when you plan?”

“Is anything making your velocity less stable?”

“What could I do to help the team become more predictable?”

Those questions keep velocity in its proper place.

The leader is not asking the team to go faster by making the number bigger. The leader is asking how to improve the system so the team can forecast, deliver, and learn more reliably.

What to Do If Velocity Is Already Being Compared

If your organization already compares team velocities, stop.

You do not need to make a big announcement. Just stop publishing the comparison.

Then explain why.

Tell teams that velocity is useful for a team’s own planning, but not for comparing teams. Tell leaders that comparing velocities encourages estimate inflation and makes the data less trustworthy. Tell Product Owners and stakeholders that the goal is better forecasting and better delivery, not larger numbers.

Then replace the comparison with better conversations.

Ask each team what would help it become more reliable. Ask what is slowing it down. Ask what decisions are waiting. Ask what the team needs from leaders.

That is a better use of leadership attention.

Signs You Are Misusing Velocity

You may be misusing velocity if leaders regularly ask why one team’s velocity is lower than another’s.

You may be misusing velocity if teams are asked to increase velocity without a discussion of what is slowing them down.

You may be misusing velocity if velocity appears in a management dashboard without context.

You may be misusing velocity if teams argue more about points than about value.

You may be misusing velocity if team members seem to estimate defensively.

You may be misusing velocity if velocity keeps improving but customers, stakeholders, or teams do not notice better outcomes.

Those are signs the metric is getting in the way.

A Better Leadership Stance

Leaders should care about whether teams are improving.

They should care about whether teams are delivering valuable work, getting useful feedback, making realistic plans, improving quality, and becoming more capable.

But comparing team velocities will not tell leaders much about any of that.

A better leadership stance is:

“I want each team to use its own data to plan honestly. I want to understand what is helping and hurting delivery. I want to remove obstacles that make teams slower than they need to be. I do not want teams inflating estimates to make a chart look better.”

That stance creates a better conversation.

And better conversations create better data.

Common Velocity Comparison Problems

Velocity comparison problems usually come from treating a planning signal as a performance score.

Turning Velocity Into a Score

Once velocity becomes a score, teams learn to protect the number instead of improving delivery. For more detail, see Common Story Point Problems.

Asking Teams to Defend Forecasts

Forecasts should create useful planning conversations. They should not become a courtroom for defending uncertainty. For more detail, see Ask Better Planning Questions.

FAQ

Can we compare velocity across teams if they use the same estimation scale?

Not reliably. Even if teams use the same set of numbers, they will not estimate exactly the same way. Teams have different work, different constraints, different skills, different products, and different definitions of what makes an item difficult.

Should leaders ever look at velocity?

Yes. Leaders can look at velocity as part of understanding a team’s ability to forecast its own work. But velocity should be discussed with context and should not be used to rank teams.

What if one team’s velocity is going down?

Ask what changed. The team may have more interruptions, unclear backlog items, technical debt, new team members, missing skills, or more complex work. A lower velocity may be useful information, but it is not automatically a performance problem.

What if we need to know which teams are performing well?

Look at outcomes, quality, predictability, customer feedback, stakeholder trust, team health, and whether the team is improving. No single metric will tell you which team is “best.”

Can velocity be used for forecasting?

Yes. That is one of its best uses. A team can use its own past velocity to forecast how much work it may complete in future sprints. Forecasts should usually use a range rather than a single number.

How do we stop teams from inflating estimates?

Do not pressure teams to increase velocity. Do not compare velocities. Make it clear that estimates are for planning and learning, not judging productivity. Then watch whether planning conversations become more honest.