When will dinner be ready? (the joys of estimation)

How long will that take?  It seems like such a straightforward question...

When planning iterations or releases, we always need a sense of time.  For development teams, this can feel like a trap.  If they estimate conservatively, they get accused of sandbagging.  If they estimate aggressively, they get beat up for not meeting their schedule.

Solving this problem breaks down into two parts.  First, you have to take the steady-state cost of maintenance, meetings, etc out of the capacity before you even look at features.  In agile, this is often referred to as setting a velocity for the team.  If you have a 40-hour work week and you estimate a 0.75 velocity, you really only have 30 hours to budget.  From my experience, estimating above 0.8 is very risky.  If you are getting below a velocity of 0.5, it probably means there's something systemic that needs to be addressed (serious product defect, organizational issue, etc).

The second part is actually estimating the work.  Here are the things that I think are most important:

1. Break things down into smaller chunks where possible
2. Have at least two developers estimate the same task when possible - this exposes different assumptions about the work.
3. Force estimates into fairly few categories.  It's really not very helpful to have something estimated at 4.5 hours.  I'd rather have categories like: trivial, half day, full day, three days, five days, and ten days.  If the estimate is in doubt, pick the bigger category.

Sometimes there isn't enough information to make any sort of estimate.  For example, there might not be a known solution to a problem.  In those cases, I think it makes sense to define an investigation task of a finite time to come up with a better estimate.  This could include actual coding, but the main point is that there is a time-capped process on something that is estimatable.  This is often called a spike.

In the end, all of these things don't guarantee accurate estimates.  But they improve the odds.  And combined with other agile practices, they can really help with predicting when dinner is going to make it to the table.

Comments

[Joel]

Trying to schedule software development would seem to be a well-understood principle yet I very rarely see much advice on it let alone books or training. It's always of the "how to use MS Project" variety. Here's some advice I put on my blog about it.

http://ideasinwiring.blogspot.com/2006/05/personal-or-project-scheduling.html

[Brandon]

I have always liked Plannig Poker. You can read more in Mike Cohen's book.