Velocity is a powerful tool for planning. The trick is to get managers to use it correctly.
Ever had that manager who says he’s read all the agile books, gets how agile projects like to flex on scope, and then tells you to go faster when the project starts to fall behind schedule?
Why do intelligent people do that?
While most managers understand intellectually that velocity isn’t a lever, many still reach for it at the first sign of pressure.
In this article I thought it would useful to remind ourselves what agile velocity is and why it’s such a good tool for planning.
What Is Velocity?
Velocity is a measure of how fast your team is going. It’s the rate at which your team turns features (user stories) into working software.
We measure it by sizing our user stories relative to each other and then summing in each iteration how many “points” of stories we’ve done.
Once you know how fast you can go, planning becomes a breeze. Simply extrapolate out your remaining work load and—voila!—you have your date.
What Makes It so Good for Planning?
Velocity is a powerful tool for planning because it’s measured. There is no wishful thinking.
No matter how hard someone wishes the project would be done by a certain date, if our measured velocity doesn’t support that, we have a pretty compelling case for changing the plan.
Now you’d think that this would be enough reason for most folks to update their plans. But reality (or what I like to call Microsoft Project reality) doesn’t always work that way.
Promises have been made. Short-term bonuses are on the line. Those facts, combined with the drama we get from the annual budgeting process, are some of the reasons why we often see so much dysfunction on software projects.
Many projects are just systematically built to ignore reality from the start.
Which is why velocity is so powerful. It enables teams to present the facts in an unambiguous, unemotional way.
No need to get excited. No need to get emotional. We’ve got a simple case of too much to do and not enough time—which is the perpetual state of any interesting software project.
How to Use It
Now, as good as velocity is at showing when a plan is diverging from reality, you’ve still got to set expectations right up front.
For one thing, you’ve got to make sure your customer understands that your initial high-level estimates are guesses—not commitments. That’s because we don’t know what our velocity is at the beginning of a project. We have to guess. So until we do three to four iterations worth of work, measure how long that takes, and then feed that back into the plan, we can’t say for certain when we expect things to be done. We can only guess.
The second thing I usually like to do when starting a new project is to start with a spartan version of whatever it is we are building.
The thinking here is that if we can’t build a stripped-down, bare-bones version of what we want with the time and money we’ve got, then there is no way in H E double hockey sticks that we’re gonna be able to afford the more rich one (that our customer may be looking for). Better to know that now than halfway through the project.
Thirdly, if you start your project and things aren’t going according to plan, you’ve got to deliver the bad news early. I don’t mean get all excited in iteration one if your velocity isn’t where it needs to be. I mean if after three or four iterations it becomes apparent that there is too much to do, you’ve got to be upfront and share that with your customer.
I know it’s not fun, and it goes against how the vast majority of our projects have been managed in the past (management by miracle) but your customer will appreciate it, and it’ll give them a chance to reset expectations on their end.
Velocity Is not a Lever
I wrote this article because it surprised me how after reading The Agile Samurai, and going through basic boot camp training, managers I know and love were still reaching for the velocity lever, expecting it to bail them out when it became apparent there was too much to do.
It’s not that the question was wrong. Teams should always be looking for ways to go faster. It’s just that when a team is doing everything right, and going as fast as they can, expecting to be able to pull a lever and suddenly go faster isn’t realistic.
Agile projects react the same way you and I do when faced with too much to do—they do less. And asking your team to go faster is like to asking them to grow taller. It might happen, but I wouldn’t plan on it.
Jonathan Rasmusson is the author of The Agile Samurai. As an experienced entrepreneur and former agile coach for ThoughtWorks, Jonathan has consulted internationally, helping others find better ways to work and play together. When not coaching his sons’ hockey teams or cycling to work in the throes of a Canadian winter, Jonathan can be found sharing his experiences with agile delivery methods at his blog, The Agile Warrior. For more information on the Agile Inception Deck check out The Agile Samurai.