Scrum and other Agile frameworks introduce the concept of “velocity” as a measure. Velocity a ratio of some work size (story points, ideal days, etc.) verses time measured as a sprint or iteration. So a team might say “We complete 26 story points per sprint.” Or a project manager might report “Our teams complete 224 story points per iteration.”

As soon as someone gives analytical minds a number and a way to produce that number, we naturally go to work digging into its meaning. Analysis is fine when it leads to beneficial results. Many times such research leads to wasted time at best and damaging side effects at worst. Some examples:

• Velocity was average last sprint. We know we can do better so let’s push this sprint to get +10 on that number!
• The VP says she’ll take us out to the movies if we can increase our velocity by 25% this iteration.
• Team Tiger completed 30 points last sprint and we only got 23. We need to do better than them!

Before we look at these examples further, let’s take a road trip.

Driving Velocity

I live in the Phoenix, Arizona, USA metro area. Because my wife (especially) and I enjoy a famous rodent’s home in southern California, we’ve often made the 350 mile drive to that neighboring state. We know the route fairly well.  We also know that sometimes traffic, detours or other things might interfere with our usual progress.

When we arrive at the hotel our conversations about the trip never sound like:

• We averaged about 62 miles per hour this time. We know we can do better so let’s push to get +10 on that number on the way back!
• Mom says she’ll buy us extra churros if we can bump our speed average by 25% next time we come.
• My buddy Harvey drives at 80 miles per hour on this same route and we only do around 70. We need to do better than Harvey next time!

Do you talk about velocity like that after a road trip? Why not? Because the velocity is not what we are should be delivering. Let’s read that again.

Velocity is not what we are delivering.

On a road trip we are delivering a destination by a more or less certain time. While driving, velocity is important in the moment of driving, in consideration of safety and to avoid speeding tickets. No one cares if we could have gone 78 miles per hour instead of 74 in the stretch between Tonopah and Quartzite once we are in view of an artificial Matterhorn mountain!

Velocity Used Well

The three bad examples I started with all use past velocity and even some other team’s velocity. They all center the conversation around velocity, as if customers want more and more story points! Customers want working software and everything we do should be in support of delivering working software, not velocity.

I promise, if managers ask teams to deliver velocity, they will.  Most likely by cutting quality or simply increasing the scale of work size estimates, which has little to do with delivering more product.  So use velocity as an indicator, as it is used in driving.

• The team velocity now is an indicator of how much work can be done in the next sprint.
• Velocity is an indicator of what will be included within the current series of iterations making up the release.
• Velocity highlights that something is going really well or needs improvement. The improvement doesn’t come by raising velocity, it comes by making the improvement.

Let’s revisit our statements one more time, where velocity plays a part but is not the focus.

• Velocity was average last sprint. Why didn’t our new unit-test framework give us the boost we expected?
• The VP says she’ll take us out to the movies if we can get that video feature done this iteration.
• Team Tiger delivered all their stories last sprint. We need to ask them what is working so well!

There is so much more to say about velocity and how to use it. Please keep in mind the possible negative effects when we take our eyes of the product and start seeking credit for a number. And remember to deliver working software, a product, customer value, not points!