James Shore, whose work I greatly respect, wandered Twitter one day asking

I had the impulse to tell him that the name doesn’t matter, but I stopped myself, because I really meant that I didn’t mind the name very much on its own, and if James is looking for a different name, then certainly he is dealing with a significant problem. He doesn’t rename concepts for fun.

So what’s so wrong with “velocity”? It reasonably accurately describes, as James later put it, “the sum of the estimates of the stories that were started and 100% completed in the previous iteration”. I consider this the “current” or “recent” velocity, whereas when I think of “velocity” in general, it brings to mind the trend of velocity per iteration over time. This all sounds reasonable to me. So why the need to change the name? Presumably, because some people—at least, the people James was thinking of at the time he tweeted—are or were doing strange things and invoking “velocity” to support those strange things.

I think we can guess some of those strange things. The most common strange thing seems to be using velocity as a goal, rather than as information with which to, you know, manage the project.

I wrote about this at length years ago, so if you find yourself in the mood for a longer-form rant from 2008, then click here.

Does Anyone Remember Planning to Capacity?

When I first read about “velocity” (or “load factor”, if you want to go back far enough into history), I think I read something about how to use it as a way to plan based on the observed capacity of the team. I even remember reading about individual load factor! I remember reading that measuring individual load factor helped identify overloaded team members so that we could redirect work away from those people until they had a more balanced workload. It all sounds very reasonable to me, and looking back, very Theory of Constraints-like.

I do not remember recommending that we use load factor as a way to punish slow, ineffective, unskilled programmers. Why do you have those, anyway? It sounds like a risky way to invest your department’s hiring budget. I do not remember recommending that we use velocity as a way to pit teams against one another, nor as a way to establish an organization-wide ranking system for team productivity. Why would you need that, anyway? It sounds horrible—even demeaning.

What stands out most in my memory of this: the principle of yesterday’s weather. I remember some trite metaphor related to how easily one can accurately predict today’s weather: predict that it will be the same as yesterday’s weather, enjoy being right 70% of the time, then go about your day. Quick, easy, good enough. Accordingly, if we assume that the team managed to produce 21 points of stuff this past iteration, then maybe they have a 70% chance of producing 21 points of stuff in this next iteration, so we should probably plan accordingly.

Please don’t rush past that last sentence. Read it again. Let me help you.

Accordingly, if we assume that the team managed to produce 21 points of stuff this past iteration, then maybe they have a 70% chance of producing 21 points of stuff in this next iteration, so we should probably plan accordingly.

WE SHOULD PROBABLY PLAN ACCORDINGLY.

(I need Garrett Morris at a time like this.)

The Source of Our Trouble with Velocity?

I suspect that we can trace the vast majority of our problems with velocity to one simple truth: we don’t handle bad news well. We hear “you’re not going to get what you want when you asked for it” and we lose our minds. I can think of a number of good reasons for reacting this way.

  • We make important plans based on projecting a team’s velocity.
  • We feel pressure to deliver, but we’ve been forced to delegate some of that responsibility to others that we don’t entirely trust.
  • We have good reason not to entirely trust some of the people doing some of the important work.
  • We blame unreliable people even in spite of the fact that we know that not all their unreliability is their fault.
  • We accept pressure to deliver, even though we recognize that a lot of it is nothing but false urgency.
  • We know that we have too many programmers, and we have no better way to evaluate their work, and “something is better than nothing”
  • …
  • …

It becomes very complicated very quickly, with a lot of positive feedback loops of negative feelings. We can’t fix that problem overnight. Some of those problems we will never, ever fix. So what do we do?

Planning to Capacity is the Best Defence

Forget about “a good offence”. The best defence in this situation is to plan to capacity, because that’s the best measure of flow of value you have. While you figure out how to deal with all the other problems, you really should take your team’s velocity seriously, and stop treating it like a configuration setting you can change at will. It just doesn’t work that way. Instead, when you see how slowly (sorry) value is flowing out of your team, plan accordingly. Don’t just beat them over the head. Don’t just tell them to work harder. Plan accordingly while you look for ways to help the team improve their work systems.

In the meantime, if the people around you are spinning their wheels, wasting precious energy yelling about “velocity”, then you could start talking about “capacity”. Maybe that might help. “How do we increase the capacity of the team?” feels like it might lead in a more productive direction than “Can’t the team go any faster?!?!” In this respect, I agree: forget “velocity”, while you’re helping your organization figure out to really forget velocity.

Of course, actually “going faster” takes hard work, but there are some things that you can do to get started. Unfortunately, there are about 716 things that you can do to get started, and you’ll probably find that bewildering. You need help figuring out what to start trying next. For that, we would need to talk.

You can start by asking me a question as long as you don’t mind waiting an unpredictable amount of time for the answer. If you need answers sooner, then join my learning group and start getting answers today. If you need deeper, more urgent help, then book an appointment with me where we can discuss how much that would cost.