Software engineering here: Divide the project into smaller pices. If your estimate for a piece is more than a day, it is still too big. To make sure you know

Software engineering here: Divide the project into smaller pices. If your estimate for a piece is more than a day, it is still too big. To make sure you know what is involved in implementing a piece by always including how to perform a function-test of the piece. This is powerful for those pie-in-the sky estimates that go "Ohh, that cant be so difficult..." When it comes to fixing small bugs, verifying bugfixes, or other repetitive work, collect historic and use the average time, and multiply it with the number of things to do. With this approach, I typically manage to time-estimate well enough for a 3 week sprint. I have also began using a burn-down chart where I input number of hours worked on the project each day, so in the chart i can see how my remaining time burns down, and on top of that how many hours i did work each day. Making the remaining time bars black and the hours-spent fire-yellow, it is a really pretty "burn down" chart. If the fire is as big as the estimate decrease, im spot on with my estimates.