More on Estimation (+/- 10%)

My one reader One of my readers commented about my earlier post on estimation, and how difficult it is.  I firmly believe that good estimation is one of the Black Arts of Software Development - learn how to do it, and the world is at your feet; do it badly, and you lose your soul to a void of despair, or at least a void of much unpaid overtime.

The first thing to do when asked for an estimate is to recognize it.  Sometimes your boss comes to you with a question that carries a hidden agenda.  Spotting these leading questions is usually not hard, because they tend to be asked by your boss when s/he appears at your door unannounced, with a nervous smile, and asks something that seems curiously specific.

The second thing to do is make sure that once you know why they are asking, that you know how big the thing is.  This may entail some time educating the questioner about all the real details so you can give an estimate that at least is about the thing they think they want.

Next, you need to break down the job  into smaller tasks.  From experience, I think that nothing is smaller than a day, and you cannot accurately estimate anything longer than 5 days.  So start breaking the task down into discrete sub-tasks until everything is in the 1-5 day range.

Now, you may be objecting that there are some things that take almost no time to do, and you could do 5, 10, maybe 15 of them in one day, cutting your estimate significantly.  Perhaps you can do a number of the things in the same day, but there are always unforeseen complications in any workplace that will make things drag out, so the 3 tasks that were going to take one day end up taking 2 because you had to add a new accessor method to a library class and add the tests for it, and the build process did not pull in the correct version, or you had to merge someone else's changes in before you added your stuff, etc.  Leave that padding in.

Now that you have a detailed, 1-5 day breakdown of the task, spend a little time looking at the amount of time you think this will take, and consider the other things going on across that time.  Does it fall across Christmas, when nearly everyone will be taking time off at the same time, so you won't be able to get in touch with anyone if you're in the office working?  How about summer vacation, where someone important might be totally unreachable for 2 weeks?  Or does it straddle the big release of the current product, which will result in a lot of field issues?  Use this info to estimate how much of your day will be spent a) dealing with these other issues, and b) being interrupted.  Having to spend 2 weeks digging through a month's worth of log files looking for a root cause will cut your progress to a snail's pace, as will having to attend twice-daily status updates.  Remember, it can take up to 15 minutes to regain mental context after an interruption.

Finally, take the number you have, adjusted for expected interruptions, and add a fudge factor of 30% (initially).   This will give you a reasonable starting point, with some room for pulling things in (as all bosses are wont to do), but without the congenital optimism we developers seem to have.

(And another suggestion from www.codesqueeze.com might be useful, if you boss doesn't have the hearing difficulty that cuts off the upper bound of a range)

Of course, there is always the method I read about early in my career - take your initial estimate, multiply by 2, add 5, then convert to the next highest time unit)

---