[ohthehugemanate]

The benefits described here are achieved by ANY abstracted estimation system. Ask people to estimate in units of difficulty, complexity, cups of coffee, whatever. Keep those units consistent relative to each other (a 4 cup task looks roughly twice as big as a 2 cup task, in advance). Track the relationship between units and hour/days over several sprints, and your average automatically factors in all the external things like team collisions, illness, developer downtime, refactoring, bugfixes, release process, etc. The research shows that the law of large numbers makes this MUCH more accurate than pure time estimation. (time estimation is extremely difficult to get correct more than about 35% of the time; averages of consistent units are correct enough to run a casino budget).

The scrum people will tell you to call this unit "story points", but it doesn't matter what you call it, as long as it's based on something connected to task duration. Difficulty, complexity, risk, whatever.

Note that if you're tracking the conversion rate between developer estimated hours and real hours, you're already doing this. But you'll get an increased accuracy by using units that are explicitly not time-related, just because of quirks in how human brains think about time.