Written by Paul D. Race for BreakThrough Communications, btcomm.com. Copyright © 2017 All Rights Reserved.

In everyday use, the word “velocity” simply means speed. If you’re barely obeying the speed limit in a 35mph zone, your velocity is about 35 miles per hour.

But in Agile methodologies like Scrum that use short, predetermined development cycles (usually called “sprints”), the word “velocity” means something else, and its meaning has evolved over the years.

As the word is used now, the only thing “velocity” measures in any worthwhile sense is trends. Sure, a Scrum master might say, “Our team finished 4 user stories (or some other metric) last sprint.” But there’s no way to know if that’s “good” or “bad,” unless you compare such figures to previous sprints. In other words, “velocity” is mostly a way to determine if a single team is getting more efficient from sprint to the next.

Establishing a Baseline:

First each team establishes a baseline that measures tasks accomplished. For example, some Scrum teams might try counting how many “user stories” they get done per sprint. The first sprint, they get six done. That’s neither good nor bad; it’s just a figure that can be used for comparison in future sprints.

The next sprint, they get seven user stories done. That’s probably good. The next sprint they get five user stories done. That may be bad. I say “may be,” because these might have been really hard user stories compared to the ones in the first three sprints.

A simple way of illustrating this might be using a train that runs on the same schedule every day. The first day (sprint), the train hauls six cars. The second day, the train hauls seven cars. So far so good. On the third day, the train hauls only five cars. But they are bigger cars. Is the train’s productivity increasing or decreasing?

Using Point Values:

To compensate for the difference in difficulty of user stories, some Scrum teams assign “point values” to user stories and use those point values to figure velocity.

A user story they expect to be easy to complete might be three points, and one they expect to be harder might be six points, and a really hard one might be nine points. Of course all of this is subjective; a user story might be a lot easier or a lot harder to complete than it seemed during planning. Still, using an appropriate scale of “point values” to measure velocity tends to track productivity better than just counting the number of user stories, because it takes the varying difficulty of the user stories into account.

To use our train example above, you can see that on the third day, the train was more productive than on the second day, even though it had fewer cars, because the cars were bigger. Similarly, using “point values” or similar means of quantifying each user story may help you to better track the amount of work being done in each sprint.

In the following picture, the train is hauling the same number of cars (user stories) each day (sprint). But you can tell that productivity is increasing, because the cars are getting bigger on the average.

That’s why velocity calculations that take into account the relative “size” of each user story can be more useful than simply counting user stories.

What Tracking Velocity is Good For:

Once a team has determined a metric that seems to give them the information they need, tracking that from sprint to sprint helps them to see if their productivity is staying on track or improving. Generally, as the team learns to work together and individual skills increase, velocity will begin showing a slight increase from one sprint to the next, as shown in the train graphic above.

Velocities that don’t increase or that trend slightly down might not be a bad sign – maybe the team is moving to a harder part of the project and they’re underestimating the difficulty of the new user stories. But velocities that are “all over the map” from one sprint to the next might reveal either that the team needs to get better at estimating, or that there are serious problems in execution.

When Tracking Velocity is Misused:

Unfortunately, some folks in leadership position have misused or misunderstood the concept of velocity to the hurt of the team. Here are some examples:

• Measuring things that don’t actually register progress, like “engineer hours” per sprint. Unless someone goes on vacation or is out sick, the team’s “velocity” is the same sprint after sprint. But this has nothing to do with productivity.
• Measuring things that are easily manipulated, like “lines of code” or “pages of text.” Such metrics may lead to “padding” that inflates the figures being measured while the quality of the work actually goes down.
• Trying to compare the productivity of two or more teams by comparing velocities. Different teams working on different backlogs inevitably have different ways of assigning story points and of “decomposing” (breaking down) large user stories into smaller, sprint-sized ones. If Team A accomplishes 30, 32, 29, and 35 “story points” in four consecutive sprints, and Team B accomplishes 14, 13, 17, and 19, both teams are showing an average increase in velocity, and that’s all you can tell from those figures.
• Insisting that a team’s velocity increase or increase by a certain percentage every sprint. Being based on subjective input (including “educated guesses”), velocity trends are only useful at all when there is mutual trust from all concerned. Any external attempt to force a velocity increase breaks that trust and runs the risk of causing the team to focus on how they’re being assessed on a sprint-to-sprint basis instead of on getting the job done.

What is the Purpose of Velocity, Really?

Within Agile Scrum, the primary value of tracking “velocity” is – frankly – to demonstrate to everyone involved that, all things being equal, a team tends to get more efficient as time progresses. If the velocity curve begins showing something else, then it’s up to the team to evaluate its own progress, and make adjustments if necessary. Such adjustments may include:

• Mitigating or finding workarounds for impediments that have begun to impact progress more than they used to.
• Revisiting how story points are calculated to reflect that the current backlog’s stories are more complex than the stories they were doing earlier.
• Encouraging team members to work within their areas of strength instead of cross-functionally until the next “bump” of complex stories is past.

Note that none of these approaches (or a dozen others that could be taken) involve telling people to work more hours or to work “smarter, not harder” or the like. Or adding more people to the team – which always changes team dynamics and usually distracts the most talented people from their duties as they bring the newbie up to speed, causing an apparent drop in velocity for the next several sprints.

Remember, even the most useful measurements of velocity are based on largely subjective estimates. And at its best – assuming that everyone involved feels trusted and is as transparent as they can be – all velocity shows is whether a team’s productivity is apparently falling, stagnating, or rising.
Fortunately, once a Scrum team with healthy dynamics and focused members “hits its stride,” velocity seems to increase “all by itself” more often than not.