Estimates or #noestimates?

Software development happens in wildly different scenarios. Do we always need estimates? Or never? Read Thorbjørn’s take on the topic!


We have been arguing about it for years, but reached no conclusion. This is my attempt to give a more nuanced view of the issue at hand. That means both sides will criticise (different) parts of this post. Oh well. As this post will show, my view on the subject is that you should avoid estimates whenever possible. Yet in certain situations, they are a necessary evil.


First of all we need to decide what an estimate even is. In the context of the #noestimates discussion, my rough definition is something like this:

An educated guess about the effort needed to solve a business problem using software, usually based on analysis or some sort of formal estimation process. The goal of this process is typically to define cost and schedule limitations for the project.

Second: Most discussions suffer from a perspective problem, as the people involved typically have different backgrounds.

To sidestep that problem, we need to set the context for the discussion. By investigating three different scenarios, we will consider the value of estimates in each one:

  • An internal development team
  • A customer — supplier project with a high level of trust
  • A customer — supplier project with a low level of trust

Disclaimer: In order to keep the length of this post from getting totally out of hand, I hope you forgive me for providing somewhat simplified examples.


These are the crazy guys who would rather not estimate anything at all, typically developing software in a permanent and mature team. Their “customer” could be an internal one, or their product could have some kind of license model. In this context, there may be less incentive to think of the work as a project. Thus we reduce the need for planning, scheduling and budgeting. Development is a continuous effort, working on whatever has the highest perceived value at any given time.

Let’s say they are profitable, and are working to achieve product market fit. They focus on two things: Experimenting to find new innovations, or solving problems that the market already expect from a product of their kind. It is not a matter of if they should build the feature or not. It’s about how they will solve the problem, and how much effort to put into it. Based on technical and domain knowledge, they instinctively have a rough idea of the effort involved. Active estimation isn’t involved in prioritization. But do they see any value in effort estimation of the selected features?

Experiments are difficult to estimate. This is the domain of lean startup and similar practices. It may not even be actual development work, it can be prototyping, sketches or whatever. When development work is involved, a valid way of control is to time box the development effort and validate output frequently. Estimates don’t provide much value here. We think we have a solution to a problem, but we’re not sure whether it will work, or what we need to do to make it so.

The must have feature is something we know that we need. Now to figure out how to implement it with minimum effort. Any known acceptance criteria is discussed, and often removed. We remove as many requirements as possible, while still providing value to the customer. It’s a good idea to validate this theory with some real customers before starting. Again, an estimate is not a necessity. Rapid delivery and evaluation ensure that development stops sooner rather than later, and effort is not wasted.


Let’s imagine a trusted, skilled supplier is hired for a development project by an existing customer. The supplier has delivered great projects in the past. The customer is confident that the supplier will deliver a great product.

There are several possible approaches here. In theory, the best is pure time and material until the customer is happy. This is development team for hire, and could work a lot like an internal team. The problem with this approach, can be that the customer has (or would like to have) a budget. Perhaps they even have a deadline for delivery. “We need predictability!” they scream, while our shoulders slump..

Some may be surprised to find that here I’d be willing to accept both fixed budget and fixed schedule. Yet, not on any terms. First of all, the supplier should still charge for T&M, but with a limited budget. As long as we have a limit on our spending level, it’s somewhat easier to accept a fixed schedule as well. If we know our team size, we can know roughly when we will be out of money. We’ll know when we will be “done”. The downside is that the customer won’t know exactly what we leave them with when the money runs out. Given our proven track record, this may be acceptable. A middle ground can be to agree on a minimum set of features delivered, without detailing these too much. We’d like to be able to negotiate the scope of each individual feature as well.

I surrendered to a fixed (or limited) budget and a fixed scope. I need something in return. I choose a flexible scope and a product owner that is available on short notice (or even part of the team). Why? We will discuss what to build during the project — and not by consulting detailed plans — but by consulting her. We’ll have a rough idea of what to build, but the details will come as we need them. As time goes by, we’ll become better equipped to decide what are the most important problems to solve.

So do we need estimates in this scenario? Sort of. The customer will likely ask us to suggest a budget. We need technical competence and domain knowledge to do that. We also need some high level estimation effort. After the development has started, we can take an agile approach. We can report progress and prioritize based on the value we deliver. Another option could be some kind of drop funding approach. Start small and get more funding after we’ve proven delivery capability.

This model is somewhat unpredictable for both parties. The customer doesn’t get to know (or get the illusion of knowing) exactly what he will get. The supplier doesn’t know how long the assignment will last. The customer can decide “good enough” at any time and stop the project. This leaves the supplier hanging, and they may end up with periods without work. My experience so far, is that customers who set a budget usually spend it even if they’re allowed to stop half way. By allowing the scope to be flexible, they just spend it better.


Suppliers in this situation may find #noestimates difficult to grasp. They are usually working in a customer — supplier context, and often on large projects. They argue that estimates are a must to enable planning, scheduling and budgeting. How else to plan the development effort? How to provide the customer with information about when you’ll finish and how much it will cost? It’s a fair assumption that customers want this information. They may not actually need it to run a successful project, but old ways die hard.

Building trust is never easy. Any customer is skeptical of a supplier they have never worked with. Solution? Demand a fixed budget, a deadline, as well as a list of Must Have features. Again, not completely unreasonable from the customer’s perspective.

Most customers have an unrealistic expectation of the precision involved in software development projects. This means that rigid contracts increase the probability of an unhappy customer. Most suppliers will of course go far to avoid that, and may end up accepting a lot of risk. In fixed-everything projects, we push some of that risk back to the customer. We do this by setting the price 30–50% higher than the most likely result. The customer buys the illusion of predictability, but at a high price.

In this situation I would still insist on a customer that is available throughout the project. We need to deliver value early and often — building trust with the customer before they expect it. Seeing early solutions to their problem will often spawn new ideas. Changes to both scope and even budget is likely. Just remember that you’re under a fixed-everything contract. Anything new you accept into the project means that something else must go.

How to come up with a fixed price for an entire project? Unless you are of the gambling type, you‘re forced to do detailed analysis of any major features. In this situation it’s hard to avoid traditional estimating. You may even need to do estimation work in connection with change management. In my opinion, the #noestimates approach is not viable in this scenario. As in any other project, there will be a lot of discovery resulting in changes that may affect the time spent. In agile projects, discovery means “Cool, we learned something new”! You’re not so lucky. You need to go somewhere and get a project management certificate to handle the mess that ensues. Sad face.

Less flexibility means we are less likely to adjust our path as well. In this scenario the project will be “better controlled”, but will likely provide less value.


Are you working in projects with fixed budget, fixed deadline and fixed scope? You will sadly not be able to make much sense of the #noestimates movement.

A somewhat less sad face if you work in projects with a higher level of trust. You will have much to gain by checking out #noestimates and other agile frameworks. Are you doing formal estimation and detailed planning? Consider why you are estimating, and if there are other ways to achieve the same objectives.

Are you working in mature, internal development teams? Are you still doing formal estimation and detailed planning? News flash: You are most likely wasting a lot of time, and creating a lot of frustration. Go check out #noestimates#noprojects and #beyondbudgeting! You can thank me later, have fun!