Reduce Uncertainty in Agile Projects with #NoEstimates Thinking

Estimation uncertainty in software projects is often not driven by the difficulty of the problem we are trying to solve, but rather by the health of our codebase, the quality of process, and how much discipline we have in our management practices. If you want to improve your estimates, then agile and #NoEstimates thinking can have the biggest impact on your team’s success.

The #NoEstimates hashtag is, effectively, a container. Within that container are many different conversations happening about estimation practices, the resulting estimates from those practices, and the business behaviors driven by these estimates.

A common reply from the skeptics is, “#NoEstimates is a solution looking for a problem. If teams want to improve they shouldn’t dump estimation, they should work on making better estimates!!!”

False assumptions about what #NoEstimates means aside, improving estimation is an interesting idea. But what does that really mean?

The Problem of Uncertainty

Let’s start with what makes estimation difficult: uncertainty. We live in a world of uncertainty, and software projects provide a great microcosm of the types of uncertainty we face in our lives.

This uncertainty can manifest itself in two ways: accidental complication and essential complication.

Accidental complication includes the things we can improve. Craftsmanship, code quality, development processes, and management practices are all examples of the types of accidental complication we can reduce and manage.

Essential complication is inherent to the kind of work we are doing. The difficulty level of a problem you are trying to solve is an example of essential complication.

J.B. Rainsberger introduced these terms at Øredev 2013. He invited the audience to consider the idea that accidental complication often dominates the cost of a feature, thereby making estimating the cost of a feature an exercise of measuring dysfunction in your software practices and codebase.

This means our estimation is often not driven by the difficulty of the problem we are trying to solve, but rather by the health of our codebase, the quality of process, and how much discipline we have in our management practices.

It reminds me of the old joke about a junior developer asking a senior developer how to make sure their estimates are “right.” The senior developer replies, “Easy! Take your estimate, multiply by two, and add two weeks.”

This is why project management offices have created Excel spreadsheets that add percentages (padding) to estimates based on past outcomes—to try to come close to accounting for the accidental complication within their organization. There are times when fixing systemic issues is cost-prohibitive, and this approach can work.

However, if you want to improve your estimates and you agree that accidental complication dominates the cost of a feature, then agile and #NoEstimates thinking can have the biggest impact on your team’s success.

Reducing Accidental Complication

Accidental complication can exist in many parts of a project, but here are three areas where many teams can start to reduce uncertainty and improve the quality of their estimates: craftsmanship, software development processes, and management practices.

User Comments

Peter Kretzman's picture

Up until the very last paragraph, there's little to disagree with in this post. But one does marvel at how any of it can be claimed as "#NoEstimates thinking". It's all fairly obvious, and none of it is new. When a team has issues with its ability to make useful estimates, the kinds of root causes for that (e.g., code base cleanliness, management practices, team stability, and so on) that are identified in the post are standard suspects and areas for scrutiny/improvement. Read any standard book on (gasp) software estimating, such as McConnell (published 2006).
Claiming that scrutiny of those basic, well-known root causes is somehow "#NoEstimates thinking?" Please. With inclusion critieria like those, I would expect truisms like "don't run with scissors" and "brush three times daily" to be mentioned next.
Let's turn to the last paragraph now, which is the kind of illogical leap we see again and again from #NoEstimates advocates: "talk with your organizational leaders about whether playing the estimation game is necessary. Questioning the need for and use of estimates is at the core of the #NoEstimates movement". Yet, nothing in the article to that point talked really at all about questioning the need for or use of estimates; rather, it earnestly explained some basic, obvious precepts in how estimates can go awry and how they can be improved.  This disconnect makes about as much sense as if I explained at length how to eat nutritionally, and then mentioned casually, in a final paragraph, "the core of my movement is questioning the need to eat at all."

May 3, 2017 - 3:27pm
Glen Alleman's picture

Ryan, as Peter said, not much to disagree with here.

But yYou have "redefined" the two sources of uncertainty though. They are defined from the mathematics of decision making in the presence of uncertainty as

  • Epistemic - reducible, which might be termed accidental.
  • Aleatory - irreducible, which might be termed essential.

Epistemic uncertainty comes from the lack of knowledge. Epistemology is the study of knowledge. This uncertainty can be reduced by gaining knowledge. Agile is a good way to do that with an incremental and iterative production of working software to test the validity of the ideas. Epistemic uncertainty has a probabilistic process. The probability that the code won't work, the probability that we've hired staff that doesn't understand the problem.

Aleatory uncertainty comes from naturally occurring statistical processes of the project. These uncertainties cannot be reduced. The only way to deal with aleatory uncertainty is with Margin. Schedule margin, cost margin, technical margin. 

Here's a briefing deck used in our Software Intensive System of Systems domain for how to deal with both reducible and irreducible uncertainty

This is the standard mathematics of managing in the presence of uncertainty mandated by the contract regulations that is applicable to all project work, no matter the domain if you remove the reporting formatting requirements. 

In the decision making processes in the presence of uncertainty, estimates are needed. They are not optional.

I would suggest a read of will show how... 

No decision in the presence of uncertainty (Epistemic or Aleatory) can be made without estimating the impact of that decision. 

This is not opinion, this is not personal experience talking, this is a mathematical fact of the theory of decision making. Ignore this theory and the principles on which it is based at your own risk.

So the conjecture of talking about whether estimating is necessary starts with the Value at Risk of course. Low risk, or low value in higher risk, estimates can be and many times are not performed. "We're willing to just try it and see what happens." 

Without an assessment of the Value at Risk, that statement has no basis in fact for those paying your salary.

This is the fundamental misunderstanding in #NoEstimates. It's not your money. If it is your money do with it as you wish. 

Other than the last paragraph and the misdefined sources of uncertainty the bulk of the post is useful for those just coming to the estimating experience. 

For those interested in the principles, processes, and practices of estimating in the presence of uncertainty on agile projects Chapter 5 of this resource might provide some help

May 4, 2017 - 11:15am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.