My Slicing Heuristic Concept Explained

(first published on May 31st 2016, migrated from my deprecated Wordpress site)

This is a concept I devised a couple of years ago, and it seems there is a new #NoEstimates audience that would like to know more about it.

A Slicing Heuristic is essentially:

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.

Crucially, the heuristic also describes success criteria to ensure it is achieving the level of predictability we require.

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 your software delivery lifecycle. It is most effective when used for all levels of work, but can certainly be used for individual work types. 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.

However, if you are able to incorporate this concept from the portfolio level down, the idea is that you define each work type (e.g. Program, Project, Feature, User Story, etc.) along with a Slicing Heuristic, which forms part of that work type’s Definition of Ready.

For example,

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

or

“A user story ready to be worked on must have only one acceptance test”.

The success criteria will describe the appropriate level of granularity for the work type. For example, you might want user stories to take no more than 3 days, and features no more than 2 weeks.

Here is the really important part. The idea is not to slice work until you estimate it will take that long. You never explicitly estimate the work using the Slicing Heuristic. Instead, as the work gets completed across the various work types you use the heuristic(s) to measure theactual cycle times, and then inspect and adapt the heuristic(s) if required.

At the user story level, I’ve found the “1 acceptance test” heuristic to be consistently effective over different domains for creating an average story cycle time of 3 days or less. However, there are alternatives. Instead of acceptance tests you could use e.g. number of tasks:

"A user story must have no more than 6 tasks".

Here is an example Slicing Heuristic scenario for a Scrum team using the feature and user story heuristics described above:

• Product Owner prioritises a feature that she wants worked on in the next Sprint
• PO slices feature into user stories
• If feature contains more than 4 stories, it is sliced into 2 or more features
• PO keeps slicing until she has features consisting of no more than 4 user stories; they are now ready to be presented to the team
  Note: Unless this is the very first feature the team is developing, the PO now has an estimate of how long the feature(s) will take, based on historical cycle time data for the feature work type; no need to ask the team how long it will take
• In Sprint Planning, team creates acceptance tests for each user story
• If there is more than 1 acceptance test, story is sliced into 2 or more stories
• Team keeps slicing until all stories consist of only one acceptance test
  PO now has an even more reliable forecast of when the feature(s) will be delivered because she can now use the user story cycle time data in conjunction with the feature data
• Team delivers each story, and records its cycle time in a control chart
• If a story is taking longer than 3 days, it is flagged for conversation in Daily Standup
• Multiple outliers are a sign that the heuristic should be adapted in the Sprint Retrospective
• When the feature is delivered, its cycle time is measured also
• Again, if features are taking longer than is acceptable for the heuristic, the heuristic should be adapted to improve predictability (e.g. reduce maximum number of user stories per feature to 3)

Thanks for reading! If you are looking for help with your software or product delivery, I provide agile coaching, public training (both theory and practical) up to executive management level, and more. As well as public events, I can also run training internally in your organisation for a massively reduced cost, so please ✍ get in touch.