# Friday, 16 August 2013

I recently blogged here on Is Estimation Waste and I would like to come back to it. There is a movement in Lean and Agile towards #NoEstimates which has a lot of  value, but I still believe that we are risking missing something if we don't find an alternative method to get the value we get from Estimation (shared tacit knowledge just before we start work on the Work Item) when we throw away our Estimates.

Wall1

So with that warning all done, how do we go about throwing away estimates? To start simply, we need to size our Work Items instead. This is something we all already impicitly do before we bring 'stories' or Work Items in to be estimated, but now we just need to be a bit more granular with it.  Let me use a metaphor.

A dry stone wall is an ancient British technique for building walls using stones with no adhesive cement, hence 'dry' stone wall. This skill has allowed what is essentially a cleverly constructed wall which is a pile of stones to stand solid for hundreds of years in some of Britain's most exposed and weather beaten areas. 

As you can see in the photo to the right, each stone in the wall is a different size and shape, every stone is unique. However while some stones are small and some are large, none of them are Boulders, and none of them are pebbles. Each stone is small enough to be lifted into place by a single person.  

Interestingly there is a rule in dry stone walling, you don't go looking for a stone to fit a place, you pick up the next stone and do not put it down again, you find a place to use it. 

BouldersThe point I am making is that you cannot use Boulders in the wall, they are too big and unwieldily, so boulders have to be broken down into stones, and once a stone is stone sized, it gets used as soon as it comes to the top of the pile.  It would be hard and also pointless to estimate how big each stone is, they are all irregular shapes with sloping sides and pointy bits. 

This is the same thing as sizing your Work Items. Like a stone, every Work Item is unique, with differing size, complexity and emergence (all work items are likely to have some differing level of emergence in a Complex Adaptive environment). It takes much less effort to look at a proposed work item and decide if it is a 'stone',  a 'boulder', or even a 'mountain'. If it's bigger than a 'stone' get out your hammer and cold chisel and start breaking it down into stones. Judging if a Work Item is 'stone' sized takes very little effort for a very small number of people, much less effort than estimation.

BreakingRocks

So by sizing them using maths with only 11 previously completed work items I can give 95% likelihood that any new work item will be smaller than our current largest. Contrast that with using Estimation instead. Once you have 11 work items finished each of them stone sized, you know the 12th work item is likely (this is the mathematical version of the work likely) to be smaller than your largest completed work item and larger than your smallest completed work item with a probability of 90% without even knowing anything about that new work item other than it has been sized to be a 'stone'. This is statistics working from us, and with more data points the accuracy of the prediction increases. It is also worth noting that of the 10% tolerance with 11 data points, 5% of that is the likelihood of the new work item being larger than your current largest work item, and 5% is the likelihood that it is smaller than the current smallest. Most of us aren't going to worry to much if it comes in smaller, so you have 95% likelihood that the new work item is smaller than your current largest. 

Remember we work in a Complex Adaptive scenario with continually changing context, and each Work Item requirement is also Complex and Adaptive, so we have multiple levels of emergence in the work we do. So no matter how good we think we are at estimating (and if you don't measure back on completion you don't know how good you are, and that is even more Failure Demand to work it out) we are at best going to come out with roughly 60% accurate estimates. That number comes from empirical study. 

So with simple (quick) sizing with low amounts of waste we get accuracy above 90% as soon as we have completed 11 work items (and most teams have already completed many more than 11). With Estimation which usually happens after sizing has already happened - we often call sizing grooming or story refinement in that scenario - we only get 60% accuracy. I'm not here to tell you that you're doing it wrong, but if you are spending more effort to get 30% less accuracy in your predictions, you might want to have a think about why you are doing the estimate in the first place. 

Remember,  if you are going to stop estimation, you need to find a way to replace the real value in estimation - the shared tacit knowledge. Even if that means you keep on estimating only to get that benefit, it seems like a useful thing to me. However, if you do keep on estimating, please do yourself a favour and throw away the estimate at the end, it's doing you no favours. Do the maths instead. It's faster and easier, and gives much more predictability that your stakeholders will love, and will make your job much less stressful. 

 

 

 

 

 



.
Tags: Agile | Kanban | Lead Time | Lean | noestimates | Estimation

Friday, 16 August 2013 11:40:06 (GMT Daylight Time, UTC+01:00)  #    Comments [2]


Friday, 16 August 2013 14:34:51 (GMT Daylight Time, UTC+01:00)
Good Blog Dan, very relevant.
Helen Meek
Friday, 16 August 2013 17:24:05 (GMT Daylight Time, UTC+01:00)
I love the analogy of the dry stone wall Dan. As it is such a time served process and the output is high quality, I think it illustrates that simple rules can be used to great effect.

Think I'm going to have to work through the maths side of things so that I understand it more fully. I really like the apparent simplicity of this, especially if it stops us getting beaten up because our *estimates* are wrong.
All comments require the approval of the site owner before being displayed.
Name
E-mail
(will show your gravatar icon)
Home page

Comment (Some html is allowed: b, blockquote@cite, em, strike, strong, sub, sup) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Enter the code shown (prevents robots):

Live Comment Preview