Four thoughts. First, define what maximum and minimum effort estimate is acceptable - for example, tasks should not take less than 2 hours or more than 4. Second, communicate that contingency shouldn't be included in the estimates so they aren't padded. Instead, have some room in the overall plan for tasks to slip. Third, measure actual vs. estimates to learn how the team estimates - you'll find that some people consistently over estimate, and some consistently under estimate. Show them and have them adjust course. Finally, make sure that the people estimating understand that no answer is acceptable - it is better to redirect a task than have wide guesses.

Ask first to see if anyone has ever done that task before and how long did it take them. I also find that when I have to estimate how long a task is going to take me, I close my eyes and visually imagine myself going through all the steps it will take to complete it. I then guesstimate the amount of time it will take and then add 25% extra as a cushion.

We just started doing this properly. To start, I think it's important to define a structure for setting expectations and estimating tasks.

We use Pivotal Tracker's linear point system and aim for a certain velocity within our teams.

On each project, we meet with everyone who will be invoked to try to estimate the efforts using that point system. As the project goes along, it's the product manager's (or head engineer's, or boss man's) job to keep track of how the team is doing to execute and either estimate the timeline or de-scope features that are low priority and can be pushed for the next release.

Your job is to lead the team into a rhythm of shipping product as fast as they can with a high quality of integrity.

Happy to chat further about this stuff we recently went through it :)