Estimation Is Not a Commitment

You’ve probably heard that estimation is not a commitment. Sometimes in teams using estimation techniques, some form of accountability for the accuracy of estimation emerges. This is unfavorable for several reasons:
a) firstly, estimation is an approximation (with some probability), not a definitive result;
b) secondly, when accountability kicks in, project games emerge;
c) there are at least several factors causing estimation to differ from the actual time spent on a given task:

• Little experience in technology
• Limited domain experience
• Many concurrent tasks
• Optimistic/pessimistic bias
• Minimal/no estimation skills
• Undefined requirements
• Changes from the business side
• A different person estimating than performing the task
• Applied problem-solving heuristics
• The organization of work on tasks

Some of these are external factors or those over which we have limited control in the short term (marked in yellow, chosen entirely arbitrarily). These are elements that should typically be managed through an appropriate team process/organization. In 95% of cases, they are not, especially unclear requirements and changes in requirements. The remaining elements are mainly skills that can be learned, although this also requires time and effort.

In summary, estimation is not a commitment, due to the multitude of factors whose impact can be minimized but cannot be completely eliminated.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)