You can't estimate a month
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.
Comments
Tasks that big, I sometimes ask "How long do you want it to take?" I find that people asking those types of questions tend to already have a timeline/timeframe in mind, and are merely asking you to independently confirm. It's easier on my nerves and blood pressure to just tell them what they want to hear, and then let them deal with the deadline that whisltes by at high speed.
I agree. See my thoughts on correct estimation in here: http://anavish.livejournal.com/28297.html
@Tom,
I don't like that, because then I feel responsible for the set date.
To be honest, I don't either. A long time ago the army beat (well more accurately ran and PT'd) into me a sense of responsibility.
It depends a lot on the client. Usually you get a feel for those who have preconceived plans, and those that want honest input to help them make decisions.
However, I've learned to accept that as a consultant most business decisions are not mine to make. And, if the business wants to unilaterally make these decisions, that is not my concern. I will support them as best as I reasonably can (that is my job as a consultant), but that is all I can do.
It is interesting that you have such a large estimation units. Our minimum estimation unit is half an hour, and our maximum estimation unit is 2 days. Developer has to finish about 3.5 hours of work each day (this is for coffee, lunch, etc).
If developers says that something is over two days he is either not sure of the actual tasks or just doing summing in his head, and then others would like to know about what is he summing.
Isn't this essentially what Joel said in his classic post on software scheduling (http://www.joelonsoftware.com/articles/fog0000000245.html)?
Comment preview