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

Tags

Related Posts

Why Agile Fails

Introduction

Implementing a methodology from the Agile family is not at all easy. The problem usually lies in management, who upon superficially understanding what it’s all about, perceive the new method as a promise that from now on, everything will magically work better. It doesn’t matter if we have subpar team members and adhere to the principle that “any specialist can be replaced by a finite number of students.” It doesn’t matter if there’s complete disregard for knowledge management and skill development in the team because there’s never time for that. It doesn’t matter if people working on projects are shuffled between projects—after all, it’s about interdisciplinarity, and everyone should know everything.

Read More

Cleaning Up Code: Not Just About Refactoring Part 2

Due to formatting problems with code on Blogspot, it is recommended to read this article in PDF format. You can download the PDF version of the article here.

Read More

The Natural Order of Refactoring Under the Microscope Part 3: Extract Method

Analyzing Class and Method Responsibilities

In the next step, we examine the responsibilities of individual classes and methods, checking if they align with the intended responsibility of the class. It is best to analyze all methods and group them based on performing similar operations. We look for a place for these in other classes or a new class. Remember: if there is a significant private method in a class (longer than 3-4 lines), it should be moved to another class.

Read More