"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.

Optimals v. Maximals

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.

Instead of seeking the maximum velocity, perhaps teams should seek the optimum velocity.  What is the best speed today for working in the code we have, with the team we have, in the context we have?  What is the best, instead of the highest possible speed?

What can we change/improve/descale so that a greater speed becomes optimal? 

Too often a team will turn to chronic overtime to fix their 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 (see Goodhart's Law).  In fact, overtime just leads to bigger, more unpredictable problems. Agile methods are supposed to uncover problems, so it may be best for a team to become transparent so that velocity measures actually become useful.

Likewise, adding people may be the wrong answer.We might want to consider the optimal size of our team, instead of the maximum possible size. If we find that our small team membership is the very issue that is constraining our best optimal speed, we may want to add more people in a measured way. Even then, we should consider the optimal way to add people, not the fastest possible awful way.

Generally, the best way to increase the capacity of a team to do work is to eliminate wasteful practices, wait states, and overburden.  It may involve downsizing, upsizing, or leaving the team alone. It might require adding practices or removing them.

We can increase our ability to do work by making the code more workable and the team more skillful. 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 of progress at a sustainable pace toward a goal.

But it might lead to trending; is our velocity accelerating or decelerating? Are we doing less work with more people more haphazardly? Are we actually moving toward faster, easier, better releases that satisfy our customers?

Normal Variation

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

Since velocity has some normal variation, 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 a sudden bout of the stomach flu would ruin your plans for 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 has a prudent amount of slack figured in, based on the team's history of normal variation.

Wrapping Up

It's my belief that it would be better to not track velocity at all rather than fall prey to the typical pitfalls of velocity goals and velocity abuse. After all, velocity is a surrogate goal and doesn't consider the value and usefulness of the work that is created.

It would be better to have a low velocity and produce two useful features than to have a very high velocity and produce nothing but noise, cruft, and trouble for the users... but that is a different blog post.

This long ramble contains opinions and some link-mongering, whereas 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.