Estimates or #NoEstimates That is the Question

The concept of #NoEstimates has been around for nearly 10 years. This post explores some of the aspects of the #NoEstimates movement and its current status.

I introduced the concept of #NoEstimates in a recent agile training class I was teaching at Northwestern University. My students were aghast at the idea and treated me like a flat earther. Based on their pushback, I decided I needed to learn more about this line of thinking. (In defense of my students, the class was titled Agile Estimating and Planning!)

Background on the #NoEstimates Movement

The NoEstimates movement was founded by Woody Zuill, Neil Killick and Vasco Duarte. The three of them separately came to similar conclusions about the cost and value of estimating.

[By the way, if #NoEstimates disturbs, Zuill’s recommendations for having your entire team work together on one computer as a mob will freak you out.]

Note that the focus of #NoEstimates is on software development though it could apply to most technical projects that contain uncertainties.

Duarte wrote a book about it called NoEstimates: How To Measure Project Progress Without Estimating.

The basic idea of NoEstimates is that estimates are guesses that are used to make decisions. Even though we know those estimates are just guesses and that they are wrong, we continue to use them to inform decision-making. The cost is wasted time and effort in making the estimates and questionable decisions that result from those guesses.

If you continue to peel back the onion, you can see that the estimating process is driven by the need to control things. It is about a feeling of certainty over what will happen in the future. It comes from a place of fear.

Never mind that there is no certainty and control is simply an illusion.

Why Has the #NoEstimates Movement Become So Popular?

Though not quite mainstream, the #NoEstimates movement gained a lot of followers over the last 10 years. Let’s take a look at the arguments for this approach and see what we can learn about it.

Argument 1: Estimating Complex Work is Extremely Difficult

Estimating complex work like software development is challenging at best – there are too many variables. Do we really understand the requirements? Will every task be started at the planned time? Will every person be immediately available?

Will some sort of weird unanticipated thing happen along the way? For example, what if a Hurricane hits your development team in Tampa? What if some global pandemic craters the economy and demand for your product? What if your Ukrainian subcontractors have to stop work on your project to pick up a rifle and defend their country?

So yeah I guess you can choose to ignore those weird black swan events at your own peril. Since they almost never happen. At least only once or twice per year.

But even without those events, estimating things is difficult. Face it, we humans suck at estimating. We are optimists and we frequently underestimate how long things will take. We simplify the problem or challenge and overestimate our abilities.

This is especially true when it comes to big items.

This is described by the planning fallacy, developed by Daniel Kahneman and Amos Tversky:

The planning fallacy is a phenomenon in which predictions about how much time will be needed to complete a future task display an optimism bias and underestimate the time needed. This phenomenon sometimes occurs regardless of the individual’s knowledge that past tasks of a similar nature have taken longer to complete than generally planned. The bias affects predictions only about one’s own tasks; when outside observers predict task completion times, they tend to exhibit a pessimistic bias, overestimating the time needed. The planning fallacy involves estimates of task completion times more optimistic than those encountered in similar projects in the past.

The Planning Fallacy, Wikipedia

Argument 2: Estimates are Usually Wrong and therefore a waste of time

Because it is difficult to estimate work, estimates are usually wrong. Since estimates are wrong, they represent a waste of development time. Rather than wasting time developing a time estimate that is wrong, why not just dive in and begin work?

Just Do It!

Ok, so I know that is controversial on the face of it. But what if you were to look at all the aspects of the solution and choose the most valuable part to develop first? What if by focusing on building just that first valuable piece, you could deliver something of value to the customer?

That valuable item could invite valuable feedback from the customer about the rest of the solution. And what we learn by developing that piece could inform the remaining development.

Argument 3: Estimating sets up an Adversarial Relationship

This particular reason is compelling to me. When we are asked for an estimate of some piece of work to be done in the future, we set ourselves up. That is because estimates are often used to create commitments. And commitments about things that are uncertain set us up for potential failure.

Getting locked into a “commitment” creates fear. And by the way, “commitment” is the language used in tools like Jira and Azure DevOps for the agile team’s guess of how much work they can do in a 2-week sprint. It should be called guess, not commitment.

Many managers feel that it is their job to hold people accountable. If you give an estimate of 6 months to deliver something, your manager will feel it is their job to hold your feet to the fire.

Worse, some managers feel that part of their job is to challenge people and set stretch goals. So when you go to them with your project and tell them it will take 3 to 6 months, they might say “we need it in 2 months” just to “motivate you”.

Or they may tell you that it has to be done in 2 months in an effort to force you to be creative. What can you do to be creative when you have already told management that it will take 3 to 6 months? Well, the most common creative tool that people use is to cut corners on quality. I cannot tell you how many times I worked with teams who are being pushed like this and sign up for more work each sprint than they can possibly deliver.

One of the original authors of the Agile Manifesto, Ron Jeffries, points this out in his article:

Estimates are often used as a bludgeon to try to get programmers to work faster. This leads to unhappy programmers and to poor software. No one wins.

Ron Jeffries, The NoEstimates Movement, XP Blog

This adversarial relationship extends to other protective behavior:

• Employees inflate estimates to have a cushion.
• Employers know that the estimates are inflated so they push back.
• Managers will compare the plan to actual and treat variance as a shortcoming of the employee. This is super easy to do when teams use tools like Jira or ADO which is probably why they are so popular.
• Employees know that are being measured on the variance between actual and plan and so they actually make their actuals equal to the estimates. They game the system. They either deliver slower in order to meet an inflated estimate or they deflate the actuals to meet an overly optimistic estimate.
• And so on…

But No Reasonable Manager Would Accept #NoEstimates!

The argument given by my students is that this just doesn’t work in the real world where there are bosses, budgets, and deadlines. Bosses have budgets and they demand estimates for the work to be done.

Let me make sure I understand that.

1. Managers need estimates to make decisions.
2. All estimates are guesses and are wrong.
3. That makes any decisions based on an estimate questionable.
4. On top of that, estimates set up adversarial relationships between employees and managers and encourage bad behavior.

So exactly what problem is the estimate solving?

Are All Estimates Bad?

My experience with story point estimates is that they can be a useful tool to get everyone on the team on the same page. The collaborative effort of working as a team to estimate items helps clarify assumptions and provides a common understanding of the item being estimated.

Unfortunately, a lot of the estimating that happens on agile teams is not a collaborative effort so it doesn’t yield these benefits. Teams are divided by specialty (developers vs. testers) and don’t operate in cross-functional ways. Or the smartest person (or department manager) does all the estimates, which cuts out the team discussion and knowledge sharing.

The other downside to story points is when teams anchor the story points to the ideal time. Then they simply become another layer of complexity. [For more on story points estimating, check out Story Points Love Them or Leave Them?]

What Should We Do if We Don’t Estimate?

A colleague of mine who is a proponent of NoEstimates recommends forecasting the future based on past team performance. Sometimes called throughput accounting, it uses the past delivery rate of backlog items to forecast the future. This is how Kanban works.

Is a forecast an estimate? I don’t know.

I am intrigued by and still learning about NoEstimates. I’d love to hear your perspective.