Vacationeer's Guide: The Golden Formula for Projects

When you get on google maps to plan out your vacation and it tells you how long your trip will take you to get there, how does google figure that out? Pretty easily actually. It takes the speed limits of all the roads it finds, and measures the distance of those road segments, and with those two pieces of information it can calculate the amount of time it will take you to get there.

Or, more simply put in mathematical terms:

distance = rate * time

Projects work the same way. The only difference is that people call these things different names. For example, the “rate” of your project is how fast your team works.  For my teams, we call that velocity, which we’ll get into more later. Distance is where you’ll be when your done.  You could look at that in a lot of different ways. For a lot of projects, that is simply “how many features have been completed?” And time is, well, time.  It’s how long your team works on your project.

If you know two of these variables, then you can calculate the third. For google maps, this was a simple matter of acquiring the right data for the job.  Mainly, getting the distance of the road segments and the speed limits associated with them. Nowadays I think they even take into account for traffic to some degree, but that’s not within this scope. For projects, though, how can we figure out any of these? Can we figure out any of them? Well, let’s first start off by stating something that should be obvious at this point. You can’t get calculate two of the terms with only one piece of information. What do I mean by that? If you tell me how fast your going, that doesn’t mean you can ask me how much time and where you’ll be.  It just doesn’t make sense.

The same thing applies to projects. All too often I see project manager’s doing something to the effect of “We need features X done by such and such a date”. That’s the same thing as you asking me to solve the 3 variable problem and only giving me one variable of information. You just can’t do it. It doesn’t make sense. What happens in the real world with these projects is that they don’t deliver what was promised, or they have to push back the date. Very rarely do they under-promise and over-deliver.  That almost never happens. Looking at it in this high level clearly shows why this is so flawed. The project lead needs to know more information. If the lead knows the rate, and they know the time, then they can figure out the features (distance). Or they might know the rate, and they know the features to release next, then they can calculate how much time it will take.

It’s simple. Figure out two of the variables, and you can calculate the third. The interesting thing is what the project manager usually has control over. The manager can usually manipulate the feature set that needs to be delivered, or the date, but not both. Either way, you get one of the variables. The other one you need is the rate, or what teams refer to as:

velocity