In general estimates are risk assessments. With that in mind, I think the way to go about estimates depends on the experience level of the indivual or team. The best estimates are not only a number (or a t-shirt size), they also include a list of possible things that can go wrong (either as an internal dialog or, in the best case, written down as part of the estimation).
There are many methods to get this assessment. These are the ones I have used:
* Basic level: Write down everything that needs to be done and assign a time estimate (in hours, otherwise break down further)
* Intermediate level: Write down everything that needs to be done and assign a range of time in days (from best to worst case scenario)
* Expert level: Use an abstract scale (like the fibonacci sequence, T-shirt sizes, etc)
* "We've been doing this together for 20 years" level: Can it be done in XY time? Yes or No answers only.
In each of these levels the specific time it will take to complete the task becomes less and less specific. The reasons to keep it specific, are a) to learn how to estimate well and b) to keep people accountable. Reasons to keep it unspecific are that a) it's impossible to get a correct number for a task you've never done before, thus b) it's a waste of time to try and make an estimate accurate.
The value of all these estimation techniques is to find out where the most risk lies (usually there where the most unknowns / complexity lies). If you then don't follow up on those risks by checking in with the team, the estimation becomes useless. If you manage these risks well, you should at the very least have consistent estimates. Even if their real-time equivilant is off, it should be off by a consistent amount.
Most important of all though: Estimatation is a learned skill and not inherent to anybody (developers or managers). It takes time and practice to get going accurately.
There are many methods to get this assessment. These are the ones I have used:
* Basic level: Write down everything that needs to be done and assign a time estimate (in hours, otherwise break down further)
* Intermediate level: Write down everything that needs to be done and assign a range of time in days (from best to worst case scenario)
* Expert level: Use an abstract scale (like the fibonacci sequence, T-shirt sizes, etc)
* "We've been doing this together for 20 years" level: Can it be done in XY time? Yes or No answers only.
In each of these levels the specific time it will take to complete the task becomes less and less specific. The reasons to keep it specific, are a) to learn how to estimate well and b) to keep people accountable. Reasons to keep it unspecific are that a) it's impossible to get a correct number for a task you've never done before, thus b) it's a waste of time to try and make an estimate accurate.
The value of all these estimation techniques is to find out where the most risk lies (usually there where the most unknowns / complexity lies). If you then don't follow up on those risks by checking in with the team, the estimation becomes useless. If you manage these risks well, you should at the very least have consistent estimates. Even if their real-time equivilant is off, it should be off by a consistent amount.
Most important of all though: Estimatation is a learned skill and not inherent to anybody (developers or managers). It takes time and practice to get going accurately.