This is such a huge question, but the 3 things that have helped me most: (0) Make sure you are clear on your requirements, and spend the time to do the researc

This is such a huge question, but the 3 things that have helped me most: (0) Make sure you are clear on your requirements, and spend the time to do the research/prototype if you're not. Estimates have no hope in being right if you don't know exactly what you're going to do. (1) Break tasks up to pieces no bigger than a day's worth of work. You do this because the larger an estimate is, the larger the margin of error on that estimate is. That's the reason that the standard "multiply-by-three" rule that many people say doesn't work. (2) Document your tasks and estimates so you can refer to them when making new estimates. Otherwise, you don't learn, and you don't get better. My team really does this, and it really works. We order the historical tasks by the actual time-taken and estimate new tasks by fitting them in that ordering. Keep in mind though that it's probably more important to the people that care about those estimates that you're constantly updating them on the real situation. In many scenarios it's better to be a little late while providing high-quality work VS. being on time and providing crap. To pull that off, you have to find ways to constantly report your status/progress and get that external trust. EDIT: Added point 0 after further thought about my team's worst pain-points.