Is estimation waste?

Lean Thinking suggests that estimation is to be considered wasteful. Instead, the throughput time (lead time) for planned items is projected by using previous measurements. I always thought this was an interesting approach and today I came across this screencast about Naked Planning, a development process created by Arlo Belshee based on Value Based Planning. In a nutshell Naked Planning consists of the following.

  • A list of goals that describe objectives to satisfy the costumers needs.
  • A fixed length (7 ± 2) queue (Product Backlog). This is based on the idea that 7 is the number of things a person can keep in their mind at once and prioritize. It ensures that customers are making value prioritized decisions at all times.
  • The 7 slots in the queue are to be filled with Minimal Marketable Features (MMF) by the customer (Product Owner). The customer uses the list of goals to generate new MMFs once the development team has eaten away the top priority MMF.
  • The customer prioritizes the MMFs purely by value. There is no upfront estimation of MMF’s. This is based on the idea that cost is distributed linearly and therefore approximately constant, whereas value is distributed exponentially and therefore outweighs cost. Estimation itself is considered a wasteful task (see arguments below).
  • There is one (and only one) slot for urgent tasks, which the costumer can use to bypass the queue. The development team tries to keep this slot empty at all times.
  • The development team has a fixed amount of slots to pull MMFs from the queue; just like the Work in Progress (WIP) limit in Kanban. This depends on the size of your development team, but there should be about two slots.
  • A MMF is considered done when everyone included in the process thinks it’s done, including the customer. In the done state, the MMF is already part of an automatic deployment, so unless someone takes action to prevent it, it will end up in production.
  • Throughput time (time between ‘MMF gets added to the queue’ and ‘MMF is in production’) is projected by previous measurements. Since there are no estimates this is the only way to do this. These measurement-based projections are supposed to be more accurate than estimation-based predictions. Arlo puts a dotted line on the bottom of the queue with “Your approximate time to wait is x days”. This is what he calls the “Disneyland wait time”.

This is what I gathered from the above mentioned screencast, Arlo’s comment on this blog entry by Aaron Sanders explaining Naked Planning, this podcast from Agile 2008 and this short video from Agile 2007. I don’t think there is any “official” documentation about the process, just videos from conferences.

Estimates deliver negative business value

Arlo argues that when customers prioritize the MMFs purely by value without considering the cost at all, they actually make better decisions. Let’s say we’ve got a two by two matrix with cost on the horizontal axis and value on the vertical axis and MMFs scattered throughout this matrix. The common behavior is to choose the cheap MMFs on the left – first the ones on the top with high value, then the ones further down with low value. These low value / low cost MMFs are what Lister and DeMarco label with ‘Death March’ features. If you take away the cost axis, people only choose high value MMFs – some with low some with high cost. Arlo calls these short term value (high value / low cost) and long term value (high value / high cost) items. According to his studies, it turns out that this is a much better portfolio of MMFs than just low cost MMFs. Consequently, not giving your customers estimates to consider when prioritizing their MMFs actually let’s them make better decisions. Having estimates is therefore a negative business value proposition or as Arlo puts it: “It’s positive cost, it’s slightly dishonest and it delivers negative business value.

He further explains that not doing estimates also saves a lot of time:

I never spend any time tracking estimates, improving the team’s ability to estimate, applying math to counter the effects of holidays & sick days, etc. This estimation normalization stuff takes a surprising amount of time – as I only discovered when I stopped trying to make halfway-decent estimates. Possibly most importantly, eliminating estimates eliminates conversations like “you promised that, this week, you’d do X, Y, and Z. Where’s Z?” Instead, the conversations become “What is the relative importance of X, Y, and Z? Well, X, then Y, then, eventually Z. Can we just release X+Y as soon as they’re done? Sure. We’ll give you some warning when the release is coming close.” It opens up a lot more success opportunities, and shuts out several types of bad behavior.

Points to debate over

I find the idea from a developer’s perspective very appealing, because it takes away the dreadful task of having to come up with an estimate, but there are a couple of issues with this approach that I am not quite sure about.

  • Team motivation: How do you achieve a commitment from the team and keep the motivation up, without the looming deadline of the next sprint demo and without the team trying to achieve the estimates? One possible way to keep the motivation up is to keep regular meetings in which the team demonstrates the done MMFs to customers. Naked Planning does this by keeping demos and retrospectives as a heartbeat for the team. However, I am questioning if the motivation will be as high as with the commitment to a certain number of MMFs prior to the sprint. But maybe I am wrong. There is a study mentioned in Peopleware by Lister and De Marco, that suggests that “the highest [software development] average productivity was on those projects that didn’t estimate at all.”
  • Customer buy-in: You need to find a customer that is able and willing to make business decisions independently from the cost of the wanted MMF. From my experience with Scrum, it is hard enough to convince customers that they don’t need a detailed project plan with a big design up front. How can you justify abandoning release and sprint planning (and sprints for that matter) all together? Here Arlo draws from his experience by using the Naked Planning process with his team. In his experience, the ‘Disneyland wait time’ (the time for the 7th item on the queue to go into production) is usually never longer than 90 days. This means the customer can plan with the seven most valuable MMFs within 3 months.
Further reading on estimation: The perils of estimation (Dan North)
Image via Wikipedia


  1. Hi Manuel,

    I really enjoyed reading this article, and would like to provide my own feedback to the issues you have.

    The team is establishing an SLA with the customer which is measured by that wait time. There is an explicit promise made to deliver MMFs before their expiry date in the queue, whatever is the current wait time. A collaborative game begins to shorten the lead time, and up throughput of value with one piece flow. I also believe Arlo is using one as the limit now to encourage OPF. The Cumulative Flow Diagram (CFD) also shows visibly the amount of WIP, lead time and throughput. Mentioning visibility, this is a key element of Naked Planning. There is a board visible in the team room which shows information arrival and MMF progress, reinforcing the collaborative game. Other forms of motivation the team already uses can remain in place. Working agreements, 360 reviews, XP and pair programming, etc.

    Cost is known with the lead time. If the customer is paying 1000 dollars a day and the lead time of an MMF on average is 3 days, the cost should be obvious. Flowing MMFs out incrementally should also help realize the value quickly and provide feedback from the market for the customer to check if they are on the right track.


    • Thank you Aaron for the insights.

      Seeing the wait time as a SLA is certainly interesting from a customer’s point of view.

      I agree, that visibility is key in any process. I just didn’t touch it in this post, because it was already pretty long and achieving visibility in Naked Planning is not any different to Kanban. (Correct me if I am wrong.)

      Trying to minimize the lead time as a motivator is something I haven’t considered, but certainly valid. Do you have experience with teams trying to do so? How would you compare it to the commitment to Scrum sprint goals?

  2. The formula for test estimation is:
    drop dead date – date development is complete

    If all goes well you will get a positive number

    Thinking about the urgent slot I could see issues when there is more than one person who is the customer and want their own thing to be in there. I suppose there would have to be something in there to say once something is in that slot it has to be there until it is complete else the customer will cotton on to it and just change it every 5 minutes to suit their current needs. You have have 7 to some what control the context shifting problem

  3. Hi Manuel,

    A lot was written about how estimates are bad/useless/waste of time (see this article), etc… But at one point, you need to give estimates to your stakeholders: How much time the project is going to take, how much will it cost? How can you dodge these questions? No company in the world will tell you take as much time and as much money as it takes to finish your project… They need numbers…

  4. Great Factors that could affect Quality Software Project Estimation … Blog, – You have some good estimation software information here, and I would like to add some information about my Roofing Business Blueprint program to help people get more sales, and make more money. If you need anything from me you can contact at my estimation software website for more information, and I always have some FREE information or downloads => %URL% Thanks, David

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s