[valuearb]

Never give time estimates.

But if you are forced to give them, never give a single number. Use ranges. Your range for a confident estimate should be roughly 4x between the fastest and longest components. For example, 1 to 4 hours for a task you are very confident about. For things you have less confidence on, your range should be closer to 8X.

Why do this? Because wide ranges are the ONLY accurate software engineering time estimates. You need to communicate the inherent lack of precision in any estimate. For every time estimate you don't know

1) How many hours a day you'll be allowed to actually code, outside of meetings, standup, planning sessions, emergency bug fixes, etc, etc. 2) Which member of your team will actually end up doing it, the fastest one, the slowest one, or someone in between. 3) How many days will be lost to illness or personal issues. 4) How much the actual feature or story will change as it's developed and they realize the design is actual shit. 5) How much other code will need to be changed when you actually rip the lid off some of the older code it will interact with.

etc. etc.

[Too]

A good way to enforce this is to always estimate things in steps of 2^x. Eg you are not allowed to estimate something as taking 20 days, it's either 16 days or 32 days. That way it's obvious that the larger the estimate becomes the more inaccurate it is and you are forced to automatically double to 32 if your "inner" estimate is 17 days.

Scrum has a similar technique only allowing Fibonacci numbers, I think the reasoning behind it is similar.

Obviously the receiver of the estimate should know that you are using this method, otherwise they might start questioning you thinking this estimate should only be 17 for example.