Reduce Uncertainty in Agile Projects with #NoEstimates Thinking

[article]
Summary:
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.

Craftsmanship
Craftsmanship is inherent to agile practices. It is called out explicitly in one of the principles behind the Agile Manifesto: Continuous attention to technical excellence and good design enhances agility.

A lack of craftsmanship can—and often will—slow down your ability to ship valuable software that delights your customers.

How much technical debt exists in your codebase? Do you refactor your code regularly? Is test-driven development in your toolbox? How about complications from legacy code? Do you have dependencies on other teams and software? How are these dependencies managed? Can you deploy features frequently?

Many teams can benefit by adopting test-driven development and reserving time to refactor messy areas of their codebase. If you’re unsure where to begin, this could be a great experiment to try first.

This is also a prerequisite to adopting #NoEstimates practices. A clean codebase makes rapid delivery and feedback possible. It also allow for simpler story slicing. Without these basics, #NoEstimates is risky.

Software Development Processes
Scrum is deceptively simple. Yes, the Scrum Guide is only seventeen pages long and can be taught during a two-day course. But the skills needed to play the game of Scrum well are far from simple, and uncertainty can creep into the Scrum team’s efforts.

Relative estimation (planning poker) is highly susceptible to volatility when accidental complication is high. Is your work too big? Teams that are working on epics instead of stories often discover that their initial assumptions about the work were incorrect and need revising—and so does the estimate.

The same types of problems can happen when the stories are unclear. Without enough detail about what the customer wants and how it will be measured (acceptance criteria), rework and revisions can happen.

Is everything priority number one? If so, work in process can get too large, which means everything is 90 percent complete but never finished. Lack of prioritization also leaves the risky stories scattered in the backlog. This can leave uncertainty and risk lurking far too deep in a project.

Partnering with your product owner is essential. At the core of every project is a well-refined and prioritized backlog. At the core of that backlog are stories. Spending time on what a good story means within your organization can help resolve many of the accidental complications listed above.

Management Practices
Does your organization know the difference between a target, a commitment, and an estimate? Does your management team know why they are asking for an estimate? Have you helped them answer that question? (It’s a partnership, right?) Can you say no to the estimation negotiation game?

Asking these questions can help uncover areas of accidental complication within your management practices.

Changes in technology, assumptions, and team members also impact your ability to estimate well. And multitasking is a silent killer of productivity and predictability. The context switching that occurs when people change tasks eats away at precious time and invalidates any estimate given about the tasks being juggled.

All of these events can act as a trigger to re-estimate the impacted work, so team stability is critical.

Reconsider Your Estimates

Uncertainty is what makes estimation difficult. Organizations have many options to consider when trying to account for the accidental and essential complications that uncertainty causes.

For teams looking to improve their estimates—and, in effect, reduce their accidental complication—the best advice I can give is to adopt test-driven development, level up your product owner skills, and partner with your management to help them learn the impacts of bad estimation practices.

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

User Comments

2 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 https://www.slideshare.net/galleman/managing-in-the-presence-of-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 https://www.pearltrees.com/s/file/preview/140338315/DecisionAnalysisfort... 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 https://www.slideshare.net/galleman/agileevm-bibliography-v2

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.