When I first heard about the Twitter hashtag #NoEstimates, it sounded weird—even heretic. How could there be a project without estimations? Isn’t it obvious to anyone that estimates are the basis for planning capacity and we can’t issue a simple quote without them?

In the two years since this became a discussion topic on social media, I’ve gone through many sessions of thinking and writing about it. This article sums up how I feel about #NoEstimates and what the movement really tries to solve.

What Is #NoEstimates?

The hashtag was created, I think, to sound controversial. But if you check out the website, you’ll see that the idea is not exactly quite as polarizing. The people who started this party, Woody Zuill, Neil Killick, and Vasco Duarte, say the discussion they raised was about exploring alternatives to estimations, rather than doing without them completely.

However, no means no, and therefore it put some people up in arms—mostly project managers. They rightfully asked, “Without estimates, how can you plan? Isn’t the customer, the one with the money, entitled to know how much the project will cost and how long it will take?”

These are very good questions.

Imagine you’re doing a kitchen makeover. You ask for an estimate from a contractor, and he tells you it will be twenty thousand dollars and will take four weeks. Now, you know he’s wrong. It will probably take twice as long and twice the cash.

But if you already knew that, why did you ask for the estimate in the first place?

If you’re thinking, “I need the estimates for the work to be done,” stop right there. If you had infinite amounts of time and money and you hired that contractor, the work would still be done, even if you didn’t ask for estimates.

We don’t need estimates. But we really want them.

Why Do We Want Estimates?

We want estimates in order to make decisions. Based on the estimate we get for a project, we can make a go/no-go decision. If it costs too much or will take too long, we can scrap the project or delay it. If we compare alternative estimates, we can choose one that fits our needs better.

Estimates also help in planning. For example, if our development project is estimated to last a year, the company will want to start marketing efforts two months before the year’s end. We’ll want to train the sales representatives a month before release. The estimates give us visibility into dependencies so we can plan better.

Obviously, estimates are important—everyone asks for them. The funny thing is nobody likes giving them.

The Problem with Estimates

Did you ever give an estimate that “magically” turned into a commitment? This organizational dysfunction happens a lot, as the inaccurate estimate becomes the deadlines against which the developer is measured.

Developers are smart, so they don’t fall into this trap twice. The developers pad their estimates, their team lead adds a little buffer, and her director makes sure the team can actually do the work based on their record by adding more spares. We can go from a few weeks’ worth of the original estimate to a few months, maybe even years.

Here, it gets messy. If we wanted the estimate to decide on a go/no-go for the project, we now have the wrong numbers to decide by!

Clever as we are, we found a solution for that, too: If we know more about the project, we’ll get a more accurate estimate (yeah, it’s a thing). If everyone agrees on the work involved, then there’s no need for the extra padding. So we convene, and discuss, and meet again, sometimes for weeks, to understand what we’re going to build. In a couple of months, we’ll have a beautiful golden number. And during that process we’ve wasted hundreds of hours of assumptions and calculations rather than actually building the product.

There are a lot of problems with estimates. Yet these are not the main issue.

Estimates Are Not Really Helpful

I’ve never seen a project canceled because of estimations. If it was valuable enough, we found a way to do it. I’ve witnessed projects delayed based on their uncertain value and risk, though. Alternatives are nice to have, but they are really worthless because at the decision point, you mistrust all of them equally. And show me the project lead who will trust my estimate enough today that he won’t ask me again in ten months where I am, so we can start doing some marketing.

We wanted estimates to help with decision-making and planning. It seems that they are not useful tools for that.

We don’t trust estimates because we suck at making them. We are biased, we’re optimistic, and we think we know what we’re talking about and that the project will be a piece of cake. Then we get surprised every time. So when we get estimates, we’re right to be suspicious.

We also have a theoretical basis for this mistrust. Steve McConnell introduced us to the Cone of Uncertainty twenty years ago. When we estimate the project, we know the least about it. The more we make progress, we clear the fog of war and estimate better. But when requirements change (and they always do), the cone opens up again, and our estimates go down the drain.

What Do We Really Want?

We want to be right. We want to make the right decision and feel confident about it. Estimates are tools, but should we rely only on them to make decisions? Maybe there is another information source available that can help us be right and confident.

Neil Killick gave this example: You need to get somewhere by train. You can ask, “When does the train leave?” and I’ll give you an estimate, which you can plan your arrival on. But if I told you I can’t estimate when the train leaves but I know for a fact trains come precisely every ten minutes, would that help you make a better decision?

Suddenly the accuracy of the estimate becomes less relevant, while the other piece of information has more impact on the decision.

What Other Types of Information Can We Rely On?

If you look around, there are other types of information besides estimates that we can base our decisions on.

• Prioritization by value: If we can estimate how much value we get, then compare it to the estimated cost, we can make a better decision. Focusing on value rather than cost can illuminate where we should invest. Planning methods such as quantifying cost of delay put value first and make it simple to compare and prioritize projects.
• Evaluate complexity: Consider how the project is similar to other projects and how much of that knowledge is transferable to your team. Was the project done before in your team? In your company? Or is it completely new? Answer this question, and see what your estimates are worth. Liz Keogh’s model for complexity evaluation can put estimates in context.
• Collect the data: Past experience is by far a better predictor than gut feelings. Velocity information from the team gives better prediction about the ability to manage similar projects. Note, however, that past velocity is not applicable for different team composition, technologies, or domains, so be careful.
• Reduce story variance: Velocity is helpful if stories don’t vary in size. If stories always take three to four days, you can predict by velocity. If story size varies, velocity as a mean doesn’t signify much and cannot be reliably used for prediction. The team needs to be skilled at cutting stories into the same size, but when they get there, prediction becomes more reliable.
• Assume you are ignorant: Former US Secretary of Defense Donald Rumsfeld has given complexity research a valuable gift by simplifying categories of knowledge: what we know we know, what we don’t know, and what we don’t know we don’t know. The first two are what we estimate, and the latter tears the estimates apart. The most important things we can assume is that we don’t know anything and that everything we think we know is an assumption.
• Enumerate your assumptions: Our estimates our based on assumptions, and it is better to discuss those before discussing the estimates. When we make our assumptions known, a funny thing happens: They can be criticized, approved, or disproved. This criticism is a small price to pay instead of relying on an estimate we conjured in our heads.
• Plan for deliberate discovery: Finally, if everything is in our heads, are estimates really the way to decide? Maybe instead, we should discover what we need to build. Instead of creating a plan based on our conjured numbers, maybe our plan should consist of experiments to prove the assumptions we have. And instead of a big plan consisting of what we think the customer wants, we can plan a set of small, cheap, safe-to-fail experiments that will show us if our assumptions are correct or not and pave the way to a successful product, rather a gigantic project failure.

Estimate or #NoEstimate? That Is the Question

There are projects done without estimates. However, it takes an understanding environment to practice this approach. If your organization is not there yet, try teaching people about the alternatives described here, to be used in addition to estimating. Limit the time for estimation research and instead plan how to get quick feedback about your assumptions.

When I started researching #NoEstimates, the idea looked weird. Since then, estimates are the ones that look weird to me. While it’s so easy to ask, “How much will it cost?” I now almost automatically try to make decisions by relying less on estimates and more on actual information.

It makes better sense, doesn’t it?