The other theory of relativity

This excerpt from the Kindle pocket guide, Practical Estimation, discusses how we can leverage our ability to compare similar things to help create reliable project schedules.

The Most Accurate Estimates You’ll Ever Get

Here’s a formula for getting estimates that are 100% accurate:

  • First, do all the work
  • See how long it took to do the work
  • Make that your estimate

This simple formula works every time, but it’s not especially useful because it provides no predictability, only information after the fact. A valuable principle, however, is contained in that formula, and that principle is this:

Knowing how long it took to do some actual work can be useful in determining how long it will take to do similar work in the future.

Phrased this way, the principle just sounds like common sense, but there’s a wrinkle. How do we gauge similarity? And what if we haven’t done any “similar work” in the past?

If you’ve ever taken your car to the shop for repair, you’re probably familiar with this principle in actual practice. Repair shops have a guide in which they can look up standardized labor times, allowing them to quote labor costs for just about any repair or part replacement. Those labor times were likely arrived at by measuring and averaging how long each repair actually took some person or people to perform.

In the software development world, things are not so straightforward. I’ve yet to see or hear about any standardized lists of development times for tasks that developers perform. Why is that? Perhaps because software development is a process of discovery more than it is one of engineering—in software we’re always trying to discover (a) what to build and (b) how to build it. There are at least as many ways of developing a piece of software as there are people to develop it. I say “at least as many” because each software developer is capable of coming up with more than one way to develop any particular piece of software. It’s a field filled with choices.

So how do we apply the principle stated above to the world of software development? One approach is to see how long it takes to do only part of the work, and apply that information to work yet to be done. That makes the formula look something like this:

  • First, do some of the work
  • See how long it took to do the work
  • Use that information to inform future estimates

That sounds fine, as far as it goes, but it still doesn’t quite address the need to compare future work with past work. In the repair shop example, we have a guide that (theoretically) contains labor times for all conceivable repairs, based on someone actually having performed those repairs in the past. All we need to know is what repair we want to perform, and we can look up a standardized labor time in the guide.

But no such guide exists in software development. Each new software product has its own unique set of components and component relationships. From a certain perspective, all software is custom software, making it impractical to create a standardized guide.

Fortunately there still remains an aspect of software that we can use for making useful comparisons, and that aspect is relative development time.

What Makes Relative Estimation Work?

Relative estimation seems to yield better results owing to the theory that human beings are much better at it than they are at absolute estimation.

For example, I may not be able to tell you how tall two adjacent buildings are, but I can certainly tell you if one is taller than the other. I can even estimate, for example, that one building is a third taller than the other.

I may not know off the top of my head how long it will take to get to the grocery store, but I know it will be longer than it takes me to get to the gas station. I can even estimate that going to the store will take, say, twice as long as going to the gas station.

These are examples of relative estimates, which are expressions of one thing compared to another, similar thing.

The same principle can be employed when estimating software development tasks. For example, I might estimate that developing a feature to allow user registration for a web service will take fifty percent longer than a feature that allows the user to log in. I may not know how long (in absolute terms) each feature will take, but I feel pretty comfortable saying that one will take longer than the other, and by about how much.

All I need to do to get an idea of when both of those features will be completed is to develop one of them, see how long that took, then apply that information to the other feature.

It is fairly common to express the relative estimates for such features in abstract units or “points.”

Velocity

At some point, which typically is before you answer your manager’s query about when a project will be completed, you’ll want to convert your abstract (point) estimates to calendar time.

This conversion takes place through the use of a conversion factor that has come to be called velocity.

Velocity says how many points of work were completed in a specific amount of calendar time, so will be expressed in something like points per week or points per sprint (for Scrum teams).

To arrive at actual velocity, you’ll have to do some actual work. Let’s say that you and your team complete 50 points worth of tasks in a week-long period. That would make your velocity equal to 50 points/week.

To predict a project completion date, divide the number of points remaining in the project by your velocity. If, for example, there are 450 points worth of tasks remaining in your project, it will take about 9 weeks (450/50) to complete the project.

You can read more about velocity in the article titled Velocity—it ain’t what it sounds like.

Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.