How to kick velocity addiction in agile development

Understand the power and the limitations of velocity as an agile development metric

How to kick velocity addiction

Is your boss (or client) addicted to velocity? Are you? 

I don’t mean being addicted to working fast, but I have seen executives fixated on increasing velocity in a way that is… unhelpful. Their stress on velocity may be impeding their projects and their agile development teams.

It’s understandable. People hear “velocity” and they think “fast.” They think “productive,” and maybe even “nimble” or “effective.” Velocity seems to embody everything that is good about agile development.

Velocity is important, but you run into problems when developers and business stakeholders have different understandings of what it means. So let’s start with definitions. To developers, velocity is the amount of work, measured in story points, a particular team can deliver over a given number of sprints.

In other words, it’s a measure of productivity. It doesn’t tell you anything about value. It tells you how fast you’re getting somewhere, not if you’re going to the right place.

An executive eager to launch a product faster might zero in on velocity and ask why it isn’t higher, or why this team’s velocity isn’t as high as that team’s. That raises a couple of problems. First, velocity is a relative metric, not an absolute one, so you can’t use it to compare teams. Every team assigns story points differently, so fixating on how one team reports higher velocity than another is like praising a speaker because it goes to 11.

The other problem is that, under pressure, teams may inflate their reported velocity by boosting their story point estimates. They’re not trying to be sneaky. They probably don’t even know they’re doing it. But when you see a team’s velocity suddenly jump from 20 in one sprint to 40 in the next to 45 in the one after that—that’s a tell-tale sign of artificial velocity inflation. Suddenly everyone is “fast,” but the project isn’t actually progressing any faster.

That’s not to say you shouldn’t measure velocity and even try to increase it. As a rule of thumb, over the first six months to a year of a project, you want to see velocity increase 10 to 20 percent. (After that, there’s probably not much more fat to trim.) You just want that growth to come from real, organic improvements. Real velocity improvements come from using retrospectives to learn what went well and what didn’t, streamlining workflows and eliminating bottlenecks.

On the other hand, if a team’s velocity declines over time, you can and should investigate why. Cycle time—how long it takes a team to complete a certain number of story points—is a related metric that can provide even more granular insight. It could be as simple as people being on vacation, or an indicator that there is a fundamental issue within the team.

As you’re watching velocity, you should pay at least as much attention to business value delivery. One of the most important roles a product owner plays is assessing the business value each story is delivering. There are some complex methodologies for measuring business value delivery, but simple approaches increase the likelihood that it will actually happen. Some product owners start with an arbitrary number of story points—say, 1,000 for a whole group of stories—and allocate that bucket based on relative value. You can also assign t-shirt sizes (small, extra large, etc.) for value in the same way the dev team does for development effort.

That said, metrics are like vitamins: It’s essential to get what you need to stay healthy, but more is not always better. One of my colleagues tells a story about stress testing a utility. The load was higher than expected, and they couldn’t figure out why. Finally, they realized that over-diligent sysadmins had put so many monitors on the system, they were actually creating the load they were trying to measure.

For me, metrics aren’t a means to an end, but a tool to identify problems or opportunities to improve. If a team’s velocity jumps around too much, I start to think, “Something smells bad about the agile process here—let’s dig into this.”

In the end, agile is about making something great that users need. And that’s a much healthier addiction.

Copyright © 2017 IDG Communications, Inc.

How to choose a low-code development platform