Estimates: the +100h joke

We have a saying in my team, that we “pull a number out of our ass” if an estimate on the spot is larger than 100h hours. As with any joke, there’s a core of truth to this. Here’s why: You don’t have a feel for how long a task spanning 40h of work is (never mind above 100h). 8h is tangible, 16h might be tangible, 40h is not tangible and 100h is funny.

The time estimate is then multiplied by the usual offset factor based on historical estimates. But, it has happened that if we make too many jokes about the number being random the time estimate is raised one notch more because those jokes shows that we still really don’t know.

Is it tangible?

What usually happens with an estimate above 16h: You start out with grand plans, you make things extra nice. Refactor this, change that, there’s still plenty of time left, right? Time looms on, and you wake up. Half the time is gone, you have still 75% of the work left, never mind the testing. And the estimate goes out the window.

At 40h this is prolonged by the fact that 40h just feels so much more. But work wise its just as much as 5*8h. When the 20th hour rolls by, you should be as done as you are on the 4th hour of an 8h estimate.

What can you do

Break it down. If any of your chunked points are above say 25h, chunk it again. The goal it to get it as close to tangible (aim for 8h) chunks as possible. At the end of each chunk you know what should be ready. Look at it like many small 8h tasks that just happen to be connected to a bigger task.

Be aware of that having done 8h chunks may give you a false security of having all the bits in place. Even with nice sequential 8h chunks on a larger estimate – the larger the estimate, the more off we are. This is because missing stuff hides on the edges of those 8h chunks. The interplay between those chunks takes more time, but are hard to factor in.

Also be aware of any gray areas or stuff you don’t know that well. Here is the other mistake we often do. We oversimplify things. If you are any bit unsure, go look at the code, think about the edits you’d make. Touch it, smell it, get some feel for it. Write down the line-numbers and files you’d change in the estimate.

Log time spent

Unfortunately work does not always align sequentially with the 8h chunks. You often have to skip between chunks. Try to keep some percentage of time / work left on each chunk. At regular intervals, stop and look at where you are, where you should be and if you’re off. The earlier you know you’re off the earlier you can start thinking about how to prioritize the time you have left before shipping date.

Its just an estimate

When you get to it, don’t forget that its just that: an estimate – that will keep changing until you’re done. Replan, re-proritize, even re-estimate if you notice (and you will notice if its above 16h) that you’re off.