Proper Units for Task Estimation

Yesterday during a planning meeting, some fellow developers provided rough time estimates for some features that have been requested by the business team. The estimates looked like the following:

• Create awesome feature X – 2 weeks
• Resize GUI component Y – 3 days
• Capture more meta information – 26 days
• Support better use of internet tubes – 4 weeks

Much planning and thought goes in to numbers like these. There are often many smaller tasks that comprise one of the estimates given. But out of any of those estimates, did any strike you as out of the ordinary?

It turns out that while those estimates might be spot on, they either don’t leave much or create far too much room for error. According to the Pragmatic Programmer, there is a lot of weighting determined by these numbers. Estimates given in weeks are often budgeted to be off plus or minus a week or two. Estimates given in days are often budgeted to be off plus or minus a couple days.

Therefore, the two week estimate is a shorter time span than the 26 day estimate, yet is given much more cushion room. Estimating a large task can be very hard, as a task that may take 26 days or 4 weeks almost screams that there are plenty of unknowns.

Here is what the Pragmatic Programmer recommends:

Duration	Quote estimate in
1—15 days	days
3—8 weeks	weeks
8—30 weeks	months
30+ weeks	think hard before giving an estimate

So what should have those estimates looked like?

• Create awesome feature X – 14 days
• Resize GUI component Y – 3 days
• Capture more meta information – 4 weeks
• Support better use of internet tubes – 4 weeks

Moral of the story: be wise when using units of time for estimation because product schedules depend on them.