* Write your requirements as 'User Stories' - discrete units of functionality that are as independent as possible and can be developed and tested as a unit. This gives you maximum feedback on how far along you are against your original scope.

* Estimate complexity, not time. For the reasons this guy gives, people suck at estimating how long something takes. However they are better at estimating how complex something is, particularly relative to other similar things. This means you can estimate each story using 'story points' (an arbitrary measure of complexity, relative to other stories), and then be reasonably confident that two stories rated the same are going to take about as long to write. There is some variation here, of course, but averaged out over all your stories you can get quite accurate results, and usually increasingly-accurate as you go along.

* The people making the estimates should be the ones that are going to be doing the work! Seems obvious, but many places have one person (often a manager or team lead) estimate a task, then have the developers build it, and then the manager gets upset that the developers are 'lazy' (i.e. his estimates were rubbish). As the author says, use planning poker with your development team. This can seem like an Agile kool-aid gimmick to those who haven't used it, but it is a very effective way of getting everyone's input. The best developers are often those less likely to volunteer information in a group setting, and this is a great way of getting their opinions without putting them 'on the spot'.

EDIT: Maybe I should politely rephrase that: If they're anything like my previous non-technical managers, I'd rather they make the most of their talents elsewhere.

Moving back on topic, the article is worth reading just for the mention of Planning Poker alone. Another moment of enlightenment for me on HN.