The Not So Fine Art Of Estimation

Noel Rappin, Friday, January 30, 2009 @ 2:55 pm

Measured Currency by Brooks Elliott

What have I been doing this week? Estimating things.

Estimating potential jobs is critically important to a consulting firm. Estimate too high, and you don't get the job, estimate too low, and you're setting yourself up for client disappointment.

Complicating matters, the job is never specified in enough detail, and you really don't want to spend too much time putting the estimate together, because that's time spent not coding.

Even if you aren't estimating potential work, being a good estimator is a very useful skill within the ordinary work of an agile development team. Being able to specify how long your next task will take makes it easier to plan iterations and determine the status of the project as a whole.

So, in the grand tradition of a blogger writing things down in order to force himself into some more systematic thinking, here are some ideas about estimating.

Shh... the Maestro is Decomposing

If I've learned one thing about doing estimates (which is a big if...) it's this: divide and conquer. Concentrate on breaking down the task into sub tasks that are roughly the same size. Don't sweat the estimate of each individual task at any greater level of detail than "roughly". Instead, pick a reasonably consistent task size, and try to split the job into all the tasks that are about that size that you can think of.

If there are enough tasks, then individual errors in how complex each task is will tend to cancel out. My experience is that estimates tend to go badly because entire chunks of functionality weren't taken into account, not because of inaccuracy in how complex each task happens to be.

For small or medium jobs, I tend to use a half-developer week (20 hours) as my unit, with the rough complexity of an normal CRUD setup for a resource, including search. (Obviously, CRUD resources that can use the Rails scaffolding significantly will take less time than this -- like I said, it's a rough guide.) Bigger jobs tend to get estimated at the one-developer iteration level (alternately, one pair for one week), roughly 80 hours as the unit. For iteration planning, I tend to use a 4-hour half day, and the average complexity of a single page in a CRUD + Search resource.

Again, those are just guidelines. The important part is to have some idea of what your reference point is, and some confidence that each task is reasonably the same size.

Including Risk

The other place where estimates break down in my experience is in failing to take risks into account. The normal tendency is to assume something like a happy path without serious unrest. My experience is that high-low estimates tend to be received optimistically by managers or anybody else looking at an estimate -- they tend to assume the low.

I'm not sure I've hit on a completely satisfying solution to this. One thing that does help is to be explicit about assumptions -- "this task assumes that integration with the third party tool will be reasonably seamless", or "this task assumes that my current understanding of the data is correct". On a large enough job, creating "risk tasks" and giving each a probability of how likely it is to be needed (like "extra time to integrate with the library" at 35%), could be used to give you a probabilistic estimate.

Done means done

Remember that a task estimate for iteration planning needs to include testing, integration, debugging, everything to get to "done done". A task estimate for an entire job, even if it's just a developer estimate, similarly needs to include developer testing, user acceptance testing, performance tuning, infrastructure deploys, and any other support pieces.

Go Back And Check

It's very helpful to go back at the end of a project or an iteration and compare the estimates to the actuals -- this is about the only way that estimating moves from an art to a science. How close was the estimate? Where did it separate from reality? How can the estimates be made better next time? This works at all scales -- our internal iteration planning tool captures actual hours versus estimates for exactly this purpose.

Related posts:

1. What should a good iteration contain
2. Bugs can’t be estimated
3. The Confluence of UXD and Agile
4. Bullseye Diagram
5. Agile Software Development and the Lazy Client Trap

Comments (1)

Software Development

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. [...] normal features, and I wanted to take a moment to try and make my point a little clearer. Bugs and estimation have been a hot topic with us lately, but interestingly we are all working on different projects [...]

   Pingback by Agile Ajax » Bugs can’t be estimated » Pathfinder Development, Tuesday, May 5, 2009 @ 11:55 pm

Leave a comment