I'm surprised that nobody mentioned the PERT-style estimation technique that is described in Robert Martin's The Clean Coder. In that method, you estimate how long it will take for 3 scenarios: optimistic (
O), nominal (
N), and pessimistic (
P). Then the expected duration =
(O+4N+P)/6 and you get a standard deviation of
This seems to work pretty well, and I've used it a few times when management really cares about how long something will probably take.
As others have commented, I've also made estimates by examining historical data ("How long did it take to do this similar thing?").
But my favorite method is to not do time estimates at all, and only do point estimates and get a velocity over iterations. If a team is fairly consistent at sizing and completing work (user stories), then you save a ton of time by not even asking how long each thing will take.
Hour estimates are fiendishly hard to get right, and they require a lot of work to break things down into small enough chunks to effectively measure. And even then they're rarely correct because there are too many variables and we forget to account for things like sickness, vacation, or even distractions.
If I have to do hour estimates, I try to only do them for smallish tasks within an iteration. I measure everything in half-day estimates (4, 8, 12 hours) unless I know it could be less. But I rarely estimate anything at less than 1 hour.