Is estimation waste?

Manuel Küblböck
Manuel's musings
Published in
5 min readJan 7, 2010

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

--

--

Manuel Küblböck
Manuel's musings

Org design & transformation, Agile and Lean practitioner, web fanboy, ski tourer, coffee snob.