I also am very bad at coming up with time estimates. Whenever possible (and when working with internal customes), I try to sidestep the issue, by promising a 'working prototype' much sooner than the customer could expect a product. Sometimes they are so delighted with this promise that I can avoid having to give a time estimate altogether. While they are picking the prototype apart and wallowing in scope creep, I quietly code the parts I didn't have time for, and then start giving them pessimistic estimates for the features I don't like and reasonable estimates for the features they really need.
I think in some organizations, the request for 'time estimates' hides two more basic questions:
By quickly producing a 'working prototype', I alleviate fears about the first question, and I'm in a much better place to address the second question once I've shaken the real requirements out of the trees. Sometimes you build the prototype and discover that the need really isn't there ... some time is wasted, but usually not too much.
This works best, of course, in an organization where a certain amount of autonomy is granted and where there is already a trust relationship established, and it pretty much sidesteps your original question, but, heh, it is the technique I use. :)
In reply to Re: OT-ish: Estimating time to code
by ptum
in thread OT-ish: Estimating time to code
by kwaping
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |