I consider Mike Cohn one of the best on the topic of Agile estimation. His 90 min presentation on how to estimate is well worth your time. I took his one day course and all of the material in the presentation appears to come from that course.
Mike is truly inspired to find the best ways to estimate. He once forced each of his teams to pick a different method of estimating, too see which would win out a la Estimating Survivor.
Learn why relative estimating is better than absolute, how too much information can lead to poorer estimates and get good at (planning) poker plus a whole lot more.
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
How big is each dog compared to the other? Photo courtesy http://www.flickr.com/photos/andreyevbr
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:
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.
