Many things about software are hard to learn but I’m convinced estimation is the hardest. Thankfully there are a number of great lessons scattered throughout the canonical books that I can pass on. Here are a few.
First, if you can’t break down the work you can’t estimate it. Search for work breakdown structure and learn how to put one together and how to use it. Your estimates will immediately improve.
Second, a corollary, if someone can’t produce something like a work breakdown structure, their estimate is no better than a wild guess. I hope if you’re reading this that you know how wild a guess some estimates are. Request estimates with work breakdown structures when possible. Or just ask what’s included in the estimate. See if the estimate passes inspection and really considers all the work that will be entailed or if its just a wild guess.
Third, estimates are best given as an optimistic (soonest it could be done) and pessimistic (latest it might be done) date, rather than just a date. Doing so keeps the emphasis on the fact that its an estimate.
Oh, yes. I almost forgot. The number one pitfall of software estimates is: estimates are not promises or deadlines. They’re estimates. That’s why giving a date range is the best thing you can do. It makes the estimate piece of it clear and visible. If you only knew one thing about software estimates, that’s the thing to know.