BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

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

Bookmarks

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

Adoption
Style

BT