Why Agile estimation and planning never works

Modern project planning: A bridge too far

Bridge builders know what the end result will be: a structure of various materials, and the work required to put them together, defined and designed in advance and worked through in a very deliberate way.

That's not to say predicting how long it will take to build a bridge is easy. Unknowns including weather events, materials delays and personnel changes can derail a carefully laid plan and push out a project timeline by months or years. However, such delays are quantifiable, and the effort to complete remaining tasks rarely changes in a major way. If someone calls in sick or materials don't arrive, just add the extra time lost to the end of a plan, and that's the new date to work with.

But what if whenever it rained, the material construction of the bridge also changed? What if a change in personnel required a complete teardown and restart on key components of the bridge? And what if the spot where the bridge was to meet land was itself a constantly moving target?

Welcome to the nature of modern product delivery. Dozens of people with different skill sets work across multiple architectures, languages and tools to build a product -- and the very target toward which everyone works changes as more is learned. Besides trying to guess at an unknown future, even the inputs themselves are unknown.

And yet, many teams try to apply the old project thinking: Look at and understand individual tasks, guess roughly how long they will take to complete, add up those estimates, and there's the final date.

Software product delivery isn't just about dealing with unknowns that might shift parts of the plan, in parts or overall. Under each and every task lurk unknowables, firmly buried and hidden, waiting to inflict compounding and exponential impacts not only on the work to be done, but often on the work already done.

We must rethink the levels of reasonable precision to aim for.

Agile estimation and planning

In the early days of the Agile movement, we tried to step in the right direction. We embraced uncertainty and moved to non-time-based estimates.

We committed to using story points as a method to gauge relative complexity, which means comparing pieces of work to figure out what was big -- and full of unknowns -- and what was perhaps smaller and less complex, slightly more knowable work items. From this, we could derive the average time to complete work items of a given size and much more accurately predict when some key functionality might be delivered.

That was, and is, a significant step forward compared with the practice of assigning hours and days to a yearlong project plan. But it's no secret that this approach often creates just as much pain as those other methods. It turns out that story points and relative sizing, often seen as a panacea in the Agile movement, are deeply flawed. After all, these are still guesses.

When teams add up story points, put them on a timeline and use them as a basis to derive actual dates, the inherent uncertainty baked into the approach creates a cascade of confusion that often goes unseen. This has led a great many projects, seemingly "Agile" in approach, to doom.

There is a step toward better ways of working that helps avoid these common pitfalls: the #NoEstimates movement.

Just say no to Agile estimates

It sounds simple: Just don't estimate. Well, there's a little more to it than that. After all, we still must know when to schedule releases, and when to arrange integrations, marketing and feedback sessions.

The #NoEstimates movement is not simply about throwing away all predictions. It focuses on the ejection of that one damaging practice that has caused so much pain: guessing how long individual work items will take.

How does one make predictions without guesses? It's simpler than you might think. It requires three key mechanisms: work breakdowns, historical data and probabilistic forecasting.

Work breakdown practices

For any data to be meaningful, we must reduce variations or spread. Large deviations represent uncertainty, and this is often where seemingly small tasks balloon, due to unknowns.

Therefore, teams engage in regular work refinement and breakdown, to deliberately explore the complexity of work and try to uncover those unknowns. Anything the team suspects will take longer than their chosen limit -- say, three days -- should be broken down into multiple smaller pieces.

This drastically reduces the impact of unknowns, and the team can uncover complexities early.

Historical data

Once work starts, the team gathers data about how long tasks take to complete and how often they get done. There are lots of approaches for this.

Flow metrics such as cycle time and throughput, visualized via cumulative flow diagrams and scatter plots, provide a way to look for outliers and deal with them early. At the same time, teams get a sense of roughly how long individual work items tend to take.

Probabilistic forecasting

Instead of assigning time values based on what the team thinks it knows about a work item that hasn't begun, use the known factors of historical work to plot the likelihood of any given work item being achieved within a given period. This removes the danger of false certainty that comes from estimation and moves toward more honest conversations about probabilities.

For example: "Given the work we have completed recently, we can say that there is only a 50% chance this work item will be done in two weeks, but a 90% chance it will be done in four weeks."

With this approach, the team makes predictions without estimation. This fundamentally alters how to approach conversations about the work. Don't try to hit arbitrary dates; instead, provide a probability of work item completion that adjusts in real time as things change. Instead of wasting time trying to make estimates more accurate, focus on finding and breaking down the riskiest items.

For your complex product, consider letting go of estimation and moving toward probabilistic forecasts and the #NoEstimates movement.

Michael Lloyd is an Agile leader who helps teams and organizations to implement and improve their Agile practices using Scrum, SAFe, Nexus and Kanban. He is an experienced agility coach, teaching and certifying Scrum and SAFe learners.