Estimation Is Not a Commitment

Table of Contents

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.)

Related Posts

Simple, Complicated, Complex, and Chaotic Systems: The Cynefin Framework

Perhaps you’ve previously encountered concepts such as complex systems, complicated systems, or complex adaptive systems, for instance when reading Jurgen Appelo’s Management 3.0, or when considering Ken Schwaber’s thoughts on the applicability of Scrum. This might sound intriguing, but it can be difficult to find logical sense in it if one lacks a certain theoretical foundation. This is where it’s worthwhile to examine Dave Snowden’s concept called Cynefin, which is based on complex systems theory, anthropology, evolutionary psychology, and cognitive psychology.

Read More

Clients Want to Be Agile...

Clients Want to Be Agile…

One of the recent meetings involved establishing (by me, MS) a way to collaborate with a client (details intentionally slightly modified or omitted, though based on a real case). The client (K) said:

Read More

Master... Master...

The Role of the Scrum Master

In the real world, there are many variations of this role. Sometimes it’s a person from the team, sometimes a manager, sometimes someone from outside the team, sometimes a specialist in being a Scrum Master, and I’ve even seen it as a rotating role within the team. So, who is it really? What’s the purpose?

Read More