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