When you plan a road trip, you’re really only concerned about figuring out one thing: how long will it take me to get there? But for projects, this isn’t always the case. The same formula applies, though.

Now that we know how to measure out velocity, we can use that metric to figure out one of two fundamental things:

  1. How long will it take us to get there?

  2. How far will we get?

Velocity can’t answer both questions for us, but if we’re willing to concede and control one of the two variables, either the distance or the time, then we can project what the other thing will be.

For example, if the team is getting pressure to release by a certain date (sound familiar?), then with your velocity you can project how many features you’ll actually have done by that time frame. If, however, the team is under pressure to get Awesome Feature X done and released, then you can use the same formula to project when that feature will be done.

With road trips my family almost always chooses to control the distance and project the time. My wife wants to go to Disney World, for example. That’s choosing the distance factor. Now if I know my velocity I can project how long it will take us to get there. On the other hand, some times we want to do a quick weekend trip to somewhere just to get out for a few days. In those cases, we’re bound more by time, because we don’t want to be on the road the whole weekend. In that case, we constrain our time window, and see how far that will take us.

This is where the real power of knowing velocity comes from. Your implementation team is the engine of you car. Understanding velocity and how it works and what it means to your team is like having a speedometer. Until you know about velocity, you’re like driving a car with a broken speedometer.

A lot of common questions of project management start being fundamentally changed when you introduce velocity. For example, a question like, “How do I make my team work faster?” changes to something like “How do I increase my team’s velocity?” I’ve seen this happen almost any time that a team embraces these concepts, and it’s not only a change in the wording of the question that is profound, but in the meaning of what is behind it. Velocity is a historical metric for your team’s progress, so asking a question like how to make that number go higher because a much more scientific question completely. The answer is can be varied, but it all comes back to where it started, with the velocity. Try something out on your team, then wait and see how your velocity changes. You’re doing an experiment now. Not only that, but you know how to measure the results.

Enjoy your new found technique. If you have any questions or comments feel free to contact me.