Empirical Measurement of Cycle Time by Slicing Heuristic

The NoEstimate movement has stumbled across a good thing, but every time I speak to someone from it, they don't present like they know what that good thing is.

One of the crucial points is that if you are going to use concepts from queuing theory, like Little's Law, you have to understand the appropriate use of the law in the context of development cycle time.

Little's Law can only be used when the team have achieved a level of stability in their story deliver that makes the variance negligible. The nature of statistical dependency and variance means that if the first stage is out by say, 25%, then depending on the number of stages, the end task could be out by 400% anyway, regardless of size of batch (fabricated example, but you can see this everywhere). If they haven't achieved that stability, then Little's Law is next to useless! Especially since the stochastic aspects are not accounted for in it. The good thing that NoEstimates brings is the slicing into small, tiny, 1 to 2 day stories automatically lowers the variance relative to the size of the story.

Plus, I'd go finer than that and suggest that you deploy a single story each time if you've reached CD, not blocks of 4 or so. Since blocking up into 4 stories doesn't make intuitive sense when working with folk who don't have an understanding of the benefits. It also implicitly encourages them to think in 4 'things' which might not be enough at all. So you introduce an unnecessary learning step for them that introduces risk.

Using small stories allows you to learn quickly and descend the cone of uncertainty quickly too. I spoke to (and eventually raged at) Woody and Nick in Macrhj of this year (goadingtheitgeek.blogspot.co.uk/2014/03/noestim...) and they'd never heard of the cone of uncertainty. So for me, whilst the NoEstimates movement is a good thing, they don't know why it is a good thing, especially in managing risk, and in spheres other than agility and aren't in the slightest bit interested in learning anything more about it from anyone else, since I got the impression they feel they wrote the book. Shame really, as this has the potential to be very useful indeed!

"Prepare backlog with Product Owner/Customer so that it is finely grained into simple stories that can be "done-done" in 1-2 days" <---- That seems like estimation to me.

Dispense with all the disjoint noestimates hype, hoopla, & jargon, and learn how to do it right. Estimate -> do the work -> record how long it took. Over time, you'll build up an accurate, empirical database to use to estimate new work. It's a simple, well-documented, unglamorous process, but nobody seems to do it (or want to do it). That's because no matter how accurate your estimates are, it's highly likely that executives will chop them in half because of "market demands".