When we think of estimation, we immediately associate some concepts that are attached to the estimation activity: listing all the work, sequencing all the work, assigning all the work, etc.
All of those activities are accessories to estimation. The fact is that a task does not have an intrinsic duration, it has a duration that varies with the assignment, the sequencing, etc.
This poses a fundamental problem for estimation proponents. If the duration of a task depends on the person taking on that task (e.g. experienced vs. inexperienced engineer), how could we possibly estimate tasks before we know who will take them?
We can’t, and to solve that, the Project Management community came up with several tools that try to remove that uncertainty. For example, in a Gantt chart, we explicitly list the duration, sequence, and dependency between tasks, in other tools (e.g. PERT), we may include also the assignment (who does which task).
So, we are left with several tools that depict some, but not all the different aspects of a project (assignment, task duration, dependency, duration in ranges, etc.)
Scope changes everything
Not ideal, because all of these can quickly change (and do in many cases) for software projects. In software projects, using those tools ends up being a nightmarish task even for some simple projects (say 5 people for 5 months). The change (or churn) in requirements, the constant addition of extra work (scope creep + bugs), makes the use of those tools impractical.
So, in order to estimate we are then left with a dilemma: do we use the tools from project management and spend large amounts of time trying to keep them up to date (and even then the estimates provided will likely be off by quite a margin), or do we look for alternatives?
In the #NoEstimates movement, we are constantly looking at how we can solve a business problem (limiting the investment and time). And we do that explicitly without using estimation because we know that strategy is catastrophic for software projects.
In the #NoEstimates workshop, I share some of the practices that allow you to make decisions without estimates. In this post, however, I’ll focus only on one counter-intuitive aspect in #NoEstimates that solves many of the problems that Project Management has been unable to solve: looking at the past to be able to make decisions about the future.
Making decisions with facts, not gut feelings
While project management uses “actuals” in part of its tracking and progress follow-up practices, it never really takes those very seriously, and instead puts all its faith in the use of estimations about the future.
In #NoEstimates, we look at actuals and use that data to make decisions about the future instead of estimating what the future could look like. For example, this heuristic: if after 5 months you are 50% way down the backlog, we already know that your project will take at least another 5 months unless we start cutting scope aggressively.
In other words, in #NoEstimates, we simply expect the rate of progress (backlog items delivered / sprint) to be largely stable over time. And when it isn’t (for example, a surprise happens), we update our view of the “actuals” and include that in the decision-making.
This has the critical advantage of taking into account the messiness of real life in a project (actuals encode all the aspects of the project: illness, vacation, interruptions, priority calls, etc.), as input to decisions about the future.
This has the critical advantage of including the messiness of real life in a project
@duarte_vasco
The #NoEstimates principle in use here is: “the future will look like the past unless something happens. And should something happen, we will know it immediately and act on it”
This counter-intuitive principle helps us make decisions faster, and keep the teams focused on the problem at hand instead of spending countless hours in estimation meetings that are bound to be wasteful because the scope will change, people will be ill, or leave, and countless other surprises.
