You can't estimate a month

time to read 3 min | 403 words

Udi is talking about not trusting a developer's estimate:

Developers don’t know how to estimate.

Or more specifically, the variance in the actual completion time of a feature from the estimate given by a developer increases probably exponentially with time.

For example, if the estimate is a day, you can expect it to be finished in around a day. If the estimate is a week (5 works days), it will probably vary between 4-10 work days. If the estimate is a month, in all actuality the developer probably doesn’t know enough to say but will answer when pressed.

I agree, but I think that he is taking it in the wrong direction. The problem is that you can't estimate a month, or a year. The reason for that is that you have too many variables to juggle, and once you break it down to tasks, even the slightest delay at any of those, spread over a month, can cause significant pain for the schedule.

And yes, I am talking about estimating a single feature that needs about a month to develop. That is not accurately estimateble.

At work, we have a fairly simple set of rules for estimation:

  • Smallest estimation unit is half a day
  • Largest estimation unit is a week
  • Everything that is over a few days needs sub tasks and rough sub estimates.
  • You estimate to the point where the code is ready to leave your machine (move to QA / Production / Etc). In other words, you estimate to Done, not Demo.
  • You are allowed to be wrong

The half-day reasoning is based on "a developer pick up the phone and went to get some coffee and it is lunch time already". I had several such days recently, and it really drove that fact home.

I may very well finish a two days task in three hours, because I am in the flow and it just works. And I may very well get stuck of something simple for three or fours hours (both of which happened this week).

So, in summary, if you want me to estimate something that big, my answer will usually be Mu. And I expect the person asking to figure it out. I fully support Udi's idea about doing it on a feature by feature basis, because then you have both immediate feedback and small enough tasks.

But, I am 84.8% done, honestly.