How to kick agile velocity addiction in agile development

Is your boss (or client) addicted to velocity in agile development?

I don’t mean they are addicted to working fast, but I have seen executives fixated on increasing agile velocity in a way that is… unhelpful, for their projects and their Agile development teams.

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

Velocity in agile is important, but you run into problems when developers and business stakeholders have different understandings of what it means. So let’s start with the agile velocity definition to understand what is velocity in agile development, and how do you measure velocity in agile. To developers, velocity in agile is a measure of  the amount of work in story points, a particular team can deliver in a particular amount of time. This can be calculated using a velocity chart in agile and the agile velocity formula.

In other words, it’s a measure of productivity. It doesn’t tell you anything about business value in agile. 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 how to increase velocity in agile and ask why it isn’t higher, or why this agile team velocity isn’t as high as that one.

Now you have a couple of problems. First, the agile velocity metric is  relative, not an absolute one, so you can’t use it to compare teams. Every team assigns story points differently, so fixating on how this team reports higher project velocity in agile than that one is like praising a speaker because it goes to 11.

The other problem is that under pressure, teams may increase their apparent agile 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 agile team 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, instead of safe agile velocity or planned agile velocity. Suddenly everyone’s “fast,” but true project velocity in agile has not increased, and the project isn’t actually progressing any faster.

That’s not to say you shouldn’t measure velocity in agile 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 the agile velocity metric increase 10%-20%.  (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 agile retrospective questions to learn what went well and what didn’t, streamlining workflows and eliminating bottlenecks.

On the other hand, if  agile team 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 agile velocity, you should pay at least as much attention to business value. One of the most important roles a Product Owner plays is assigning business value points to stories. Yet all too often this task gets neglected. It seems too time-consuming, or maybe the person isn’t truly close enough to the business to accurately estimate business value. That’s a problem. Only the business knows what’s most important to the business. Even high performing agile teams can’t prioritize stories as well as the product team can.

That said, business points are more complicated to evaluate than story points, so you need to be pragmatic in agile. 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 creating the load they were trying to measure.

The moral? Look for the middle ground. Some businesses use complex calculations to figure a metric called “earned business value,” but it’s an expensive and time-consuming process.  Our projects typically use t-shirt sizing to quantify business value, the same way we quantify story points.

The key thing to bear in mind is that while agile velocity is a virtue, it’s not the only one in Agile, and not the one most important to the business. In the end, Agile development is about making something great that users need. And that’s a much healthier addiction.