Is your boss (or client) addicted to velocity?
I don’t mean they are addicted to working fast, but I have seen executives fixated on increasing velocity in a way that is… unhelpful, for 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 ‘powerful.’ 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 in a particular amount of time.
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 one.
Now you have 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 this team reports higher velocity 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 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’s “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%-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 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. 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. The best development team in the world 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. 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 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 is about making something great that users need. And that’s a much healthier addiction.
Keith Skronek is a principal technologist at Nexient, leading the delivery team to establish, document, educate and enforce coding best practices. He has been writing code for 40 years and delivering enterprise software for 20. He writes the Pragmatic Agilist column for InfoWorld.