Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Empirical Measurement of Cycle Time by Slicing Heuristic

Empirical Measurement of Cycle Time by Slicing Heuristic

This item in japanese


Neil Killick, Independent Agile and Lean Software Professional describes slicing heuristic for the teams, which use noestimates to help them predict how much, can be done before doing the actual work.

Neil defines slicing heuristic as:

An explicit policy that describes how to "slice" work Just-In-Time to help us create consistency, a shared language for work and better predictability.

He explains this process of slicing heuristic in his blog as follows:

  • Prepare backlog with Product Owner/Customer so that it is finely grained into simple stories that can be "done-done" in 1-2 days, and ordered according to value.
  • Have the team work on the stories.
  • Measure how long it takes to accomplish the stories, use Little's law to calculate cycle time from current work-in-progress and throughput.
  • Retrospect: How long did it really take to move the story into production? Inspect and adapt accordingly, use information to size next user stories as required.

Neil says in his another blog that the heuristic also describes success criteria to ensure it is achieving the level of predictability we require.

A slicing heuristic takes more into consideration than just the mechanics of getting stories into production, but also the "ready-ready" policies that gate what should be developed rather than an arbitrary time or t-shirt size

Neil says the slicing heuristic is intended to replace deterministic estimation rituals by incorporating empirical measurement of actual cycle times for the various types of work in software delivery lifecycle.

For a team dabbling in #NoEstimates, a User Story heuristic can be an extremely effective way of providing empirical forecasts without the need for estimating how long individual stories will take.

Neil suggests using slicing heuristic for each work type like Program, Project, Feature, User Story, etc. which forms part of that work type’s Definition of Ready. He has given following example to explain the concept:

"A feature ready to be worked on must consist of no more than 4 groomed user stories"

Success criteria are used to describe the granularity for the work.

For example, you might want user stories to take no more than 3 days, and features no more than 2 weeks.

Neil says not to explicitly estimate the work using the Slicing Heuristic. Heuristic is used to measure the actual cycle times. Inspect and adapt the heuristic if for better policies.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Not quite!

    by Ethar Alali,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 ( 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!

  • Dispense with all the hype, hoopla, and jargon.

    by Anthony DaSilva Jr,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "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".

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p