I read this short article about estimation in Leading Answers and found that it covers in brief all that we need to know/to do – to arrive at a good estimate. This is so short that this can be printed on a single page and should be pasted next to you, where you can have a look at it as often as it is needed, so you don't forget the points mentioned.
Some of these point, are covered in detail in mysticMundane. I have given the point from the post in Leading Answers and the link to the corresponding post in mysticMundane below.
8.Be aware of common estimation omissions – Consult lists of common estimating omissions (such as Capers Jones’) and ensure these items are taken into account. Look back at retrospective notes for things that did not go so well, and tasks that were missed or ran late – make sure we include enough time for these.Please check here for the list of common mistakes done in software estimation.
9.Embrace reality early – As the project progresses, it is tempting to think development will get faster and faster now all the technical problems have been overcome. However don’t under estimate the load of maintaining and refactoring a growing code based. Especially if the system is now live; support, maintenance, test harness updates, and refactoring can quickly erode the velocity improvements anticipated, so use the real velocity numbers. That a newer technology doesn’t give us the order of benefits it promises to do is discussed here