Estimating the duration of software projects
2 comments
How can I improve my estimates?
I've found that the more detailed my estimation process, the less optimistic my estimates are. Generally speaking, if I break down what I'm planning on doing into units which I think should take a month each, I end up with an estimate which is 2x less than the actual time I will take; if I break things down into units of a week each, I end up with an estimate which is optimistic by a factor of 1.5x; but if I break things down into units which I think can be done in a day each, I tend to come very close to being correct.
I don't know if this trend is something other people experience; but if it is, the obvious solution is to think more carefully about all of the small steps which make up the big steps.
I've found that the more detailed my estimation process, the less optimistic my estimates are. Generally speaking, if I break down what I'm planning on doing into units which I think should take a month each, I end up with an estimate which is 2x less than the actual time I will take; if I break things down into units of a week each, I end up with an estimate which is optimistic by a factor of 1.5x; but if I break things down into units which I think can be done in a day each, I tend to come very close to being correct.
I don't know if this trend is something other people experience; but if it is, the obvious solution is to think more carefully about all of the small steps which make up the big steps.
Check out 37signals.com and BaseCamp. There are tons of books - a little google searching is in order.
All my guestimates of project duration have been so far ridiculously optimistic and I usually err by a factor of 4x or worse.
Is there any way out of this? How can I improve my estimates? Is there ANY book or technique worth learning?
Any help would be greatly appreciated.