"Managing" Velocity

The term velocity is very well-chosen. It means speed in a certain direction, with the intention that it refers to the teams rate of travel toward a product release.  I have suggested that velocity is just capacity and my intention was good and maybe even right in many ways. Velocity is the practical measure of our capacity being applied toward the completion of a release. The term still stands superior to my older suggestion.
Lets start with the definition that velocity is the speed of progress in a given direction.

The direction part gets missed. People (including my slightly younger self) want to do things like track bugs ("failure demand") as velocity. It might be good to see how much capacity is being lost to failure demand, but it is not velocity toward the same goal, not really.  We don't want to know that the team is busy, we want to see when the project will be done. So we do not count bugs toward velocity. We want to see quality problems drive velocity down; that's what velocity measurement is for. If bugs are driving velocity down, wrap a bunch of tests around your most volatile or hottest code and clean it up. Watch what happens to velocity after an iteration or two.

Some think that when I don't offer partial credit or bug points or meeting points it is because I don't care about velocity, but it is actually because I care too much about it to pollute it. Done well, velocity is the speed toward a goal.

The fact that we use words like "velocity" and "sprint" makes it sound like we are in a race. Indeed, one can see the goal as one of releasing as quickly as possible, and we can all applaud that goal. What, then, is the ideal velocity of a team? Infinity? Isn't faster always better? It feels wrong to have a velocity "dip" and teams will go to great lengths (often the wrong ones) to shore up their numbers.

Too often a team will turn to chronic overtime to fix the velocity problem. This is a huge mistake. Velocity is the amount of capacity spent in the direction of completing a release, and attempting to inflate capacity does not solve the problem.  In fact, overtime just leads to bigger, more unpredictable problems. Agile method are supposed to uncover problems, so just be transparent and let velocity become useful.


Instead, we should actually increase the amount of capacity toward a goal by eliminating wasteful practices, wait states, wasted efforts. We should increase our capacity by making the code more workable and the team more skillful. We might improve our velocity quite a bit if we do it in ways that make our future easier than our past has been. The work might get easier and more pleasant over time instead of being a never-ending "trudge in the sludge."

This leaves us with velocity as the rate progress at constant, sustainable pace toward a goal.

Even so, velocity will fluctuate. You don't have the same capacity to expend every week. Maybe you're tired from overtime, or life at home is requiring more attention. Maybe it is because estimates are imprecise or because each iteration has troubles of its own. Maybe exciting new features need to be vetted by the team. Maybe a member gets pulled out for sales support. There could be an illness or a birth. Don't bother trying to force velocity. It will stabilize well enough if you don't mistreat it. Then you can separate normal variation from special variation and can monitor the trends over time

If velocity is going to have some normal variation, then wise managers know to plan with a little slack. If you run your team at 100% capacity, there is no reserve to help with technical or requirement issues, no way to allow a programmer to participate in the proposal process or vet sales' ideas for new features. One dental appointment or sudden bout of the stomach flu would ruin your plans of success. Too much good content is written for me to try to do this topic justice, so I'll spare you.

Velocity should be a measure of actual, non-waste progress toward a goal at a sustainable pace. For planning, velocity is the same but with a prudent amount of slack figured in based on the team's history of normal variation.

This is a lot of opinion and some link-mongering, but I only promised to write up a quick summary of my thoughts. I've done my part. According to the deal on Twitter, it's your turn to start beating on it so we both may learn something from the exchange.

Cheers.