Two comments. To me providing good estimates for a single task below a half a day seems like a pointless exercise in estimation. It feels like below that threshold you're working in a micro-management environment where the task tracking is taking away from time-on-task getting things done.
For planning larger projects of multiple man years, I think the threshold is even higher for productive estimation. In those long term planning situations estimates below a half a week to a week are more appropriate, because you'll get a better plan focusing on improved requirement specs or use cases etc. This is because the uncertainty of the project completion is better reduced not via better estimates, but better definitions of the tasks or developing a better feel for the technical uncertainties leading you to better estimates. A more precise estimate is not the same as a more accurate estimate.
The second comment I'd have is that the most frequent mismatch in estimates is that programmers instinctively estimate the time narrowly focused on implementation, or the time for getting over the hump of the core problem (subconsciously I think thats because after that's done it's boring stuff that few people want to dwell upon). The estimation fix is to separately estimate design and or implementation separate from testing (fixing) and deployment. A good rule-of-thumb there is that testing and deployment will be Pi times the implementation estimate. That factor is even higher if you have a complex multi-layer subsystem / system integration testing scheme required for the project. There are so many shops that like to pretend none of this exists, and they can even manage to succeed doing that, but there's a lot of bad side effects. They're not as effective long-term, often implode after rolling that dice too many times, or will depend on the technical side to grind it out with heroic measures.
For planning larger projects of multiple man years, I think the threshold is even higher for productive estimation. In those long term planning situations estimates below a half a week to a week are more appropriate, because you'll get a better plan focusing on improved requirement specs or use cases etc. This is because the uncertainty of the project completion is better reduced not via better estimates, but better definitions of the tasks or developing a better feel for the technical uncertainties leading you to better estimates. A more precise estimate is not the same as a more accurate estimate.
The second comment I'd have is that the most frequent mismatch in estimates is that programmers instinctively estimate the time narrowly focused on implementation, or the time for getting over the hump of the core problem (subconsciously I think thats because after that's done it's boring stuff that few people want to dwell upon). The estimation fix is to separately estimate design and or implementation separate from testing (fixing) and deployment. A good rule-of-thumb there is that testing and deployment will be Pi times the implementation estimate. That factor is even higher if you have a complex multi-layer subsystem / system integration testing scheme required for the project. There are so many shops that like to pretend none of this exists, and they can even manage to succeed doing that, but there's a lot of bad side effects. They're not as effective long-term, often implode after rolling that dice too many times, or will depend on the technical side to grind it out with heroic measures.