Gerry Kirk

So you’ve gone over requirements, and have an idea of what needs to be done, then the client/project manager pops the question developers dread:

How long will it take?

Then, depending on your situation, you might:

• Give a number based on gut feel
• Look at historical numbers for something of a similar size
• Call a psychic hot line
• Break down the job into smaller tasks and try to estimate those

No matter what your approach is, estimating is just plain hard. Is there hope?

Estimate in two parts – part one: relative sizing

It turns out that we humans are pretty good at relative estimates. We can compare two or more items and agree quickly on the size of one compared to the other. Take these dogs, for instance. How much larger is the labrador on the far left compared to the poodle on the far right, assuming by large we mean height? If we gave the poodle a relative size of 2 compared to most dogs, we might say the lab is a 5. We can then give a relative number to each dog without too much effort.

Now if I were to ask you for the specific height of each dog, we’d have a much harder time both estimating and agreeing on the final number. We’re not so good at actual estimates. Estimating helps us plan, but we don’t want to spend so much time on it that the cost outweighs the benefit.

Now imagine if each of those dogs was a small feature of a system your team plans to build. We’d then have a list of features each with their relative size, and a total size for all features. That gets us the first part of estimating, that is, how much work there is to do, but we still don’t know how long it will take to do the work.

Part two: how much can we get done in a specific amount of time?

For reference sake, let’s call our unit of measure ‘points’. We can determine how long a project will take by dividing the total points by an estimated velocity. Velocity is the rate at which the team completes work. For instance, one team might be able to complete 40 points of work on average over 2 weeks. If total points is 200, then the team will need 10 weeks to complete everything planned:

200 points / 40 points every two weeks = 5 * 2 weeks = 10 weeks

So how do we determine this velocity?

There are several ways to do this, but a simple way to get started is to take a random or representative set of stories (what features are called in Agile), break them down into tasks, and then estimate those tasks in hours.

Let’s say a team that has 100 hours in a 2 week sprint. They take a sampling of stories and come up with the following estimates:

• Story A (13 points): 20 hours, 20 hours total
• Story B (8 points): 15 hours, 35 hours total
• Story C (5 points): 10 hours, 45 hours total
• Story D (13 points): 20 hours, 65 hours total
• Story E (8 points): 15 hours, 80 hours total

At this point, the team feels they can’t take on any more stories for the sprint. They leave a 20% buffer for the unexpected.

The total points planned for the sprint is 47 (13+8+5+13+8).

The team will need a little over 4 sprints to finish, so let’s call it 5: 200 points / 47 = 4.3, or 5 sprints.

We can also determine worst case / base case scenarios, based on how far along we are into the project, using what is called the Cone of Uncertainty principle. Mike Cohn talks about how to apply this in his book.

Bonus: now we can calculate project cost easily

We can also calculate the cost of the project by totaling up hours for each two week time box, or sprint as it’s typically called in Agile. If the team spends 100 hours every 2 weeks at an hourly rate of $100, then each sprint costs $10k and the project cost is expected to be $50k:

2 week sprint cost = 100 hours * $100 / hour = $10k

project cost = 5 sprints * $10k = $50k

I’ve tried to illustrate some simple techniques to create better estimates. Break the task into two parts, first calculating the size of work and then the speed at which work can get done. There is a lot more to estimating that I haven’t covered here. If you’d like to learn more, I’m hoping to offer a one day Agile course at the upcoming Plone Symposium East. If you can’t make it, please post your comment / question below.