If devs are estimating in hours, days or some other measure of time, the game is already over. As a species, we're pretty terrible at estimating absolutes. But we're pretty good at relative comparisons. If I hold up 2 buckets, 1 small and 1 large,and ask you their precise capacity in liters, quarts, etc., most guesses would be off, many quite a bit. If instead I asked you approx how much larger the large bucket was compared to the small bucket - 2x, 3x, 4x, etc., the majority of the guesses would be pretty accurate.

The better option when estimating is using a system that builds on relative comparisons between work items. We use "points" on a sliding scale. Not only does estimating get much more accurate - "We think that enhancement is about 2x as big as the one we just finished", but the estimation process is quicker.

What brings the point estimation system back to calendar time measures is mapping it to how many of those points of work are typically accomplished in a fixed amount of time - basically typical throughput. Knowing that throughout number, it's a quick calc to figure out how long it will take to complete the work. The throughput number also takes into account all of the little things that go on during the day that no one ever remembers to account for - restroom breaks, emails, phone calls, chit-chats with co-workers, etc.

I've never worked on a project that estimated things with the absolute (days, weeks, months, years) scale that was accurate and didn't require death-marches at the end. Conversely, I haven't worked on a relatively estimated project (points) that has been late or required anything like a death march to complete.