I jokingly say multiply by 2.5 and shift the unit, for example 1 hour becomes two and a half days. It seems perversely long, but it seems to catch the usual unexpected, and even most of the unexpected unexpected.

But, otherwise, I'm very skeptical of time estimation for software if it isn't accompanied by a corresponding statistical learning practice that will actually go and learn what happened when estimates go wrong.

I actually work the opposite way: I'll have something every two to three days, and then it's a matter of estimating what I'll have done by then.

This is the algorithm my manager used to estimate time when I worked:

1) Come up with a perfectly good estimate of the amount of time it will take.
2) Double that time.
3) Add a buffer to it.

He told me that most of the time, he was on time by using this algorithm.