My Slicing Heuristic Concept Explained

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)
Advertisements

7 thoughts on “My Slicing Heuristic Concept Explained”

  1. Hello Neil, your explanations are really inspiring. I was wondering if you have some examples of user stories with a single acceptance criteria? I am trying to get my head around how this can work in practice but I don’t see any of our user stories with one acceptance test. Wouldn’t one acceptance test user story be too small?

    1. Hi Dinesh. Not sure what you mean by “too small”? For me, it is important for product owners to slice customer value as thinly as possible (i.e. into increments that can be delivered to the customer, provide them value and thus they might pay us for that value), and for developers to slice those increments into ultra-thin, vertical user scenarios. So long as each slice represents a demonstrable (via an interface) change in functionality from a user’s perspective, it is not “too small”. You should check out Alistair Cockburn’s Elephant Carpaccio exercise which describes how to break down a problem into micro-slices that can be delivered in minutes.

      1. Thanks for Alistair Cockburn’s example. It however limits the problem to changes that are visible to user in some way. But it doesn’t address work that is not visible to the user. I guess we can use a combination of criteria to define a normal user story including as in your example of maximum six sub-tasks.

    1. In order for something to be considered an acceptance test or criterion, it must represent a demonstrable change in the system’s behaviour when true.

      When applying vertical slicing techniques we think about design and testability in different ways. System behaviour is always incremented via inputs and outputs. Even if those inputs and outputs are via a command line interface, we build up the system always with the goal of demonstrating working software, not simply insisting something works. This is crucial for empiricism and agile software development in general.

      1. Yes, unfortunately demonstrable software change is what we sometimes try to get around. I will try to get this across my teams. Thanks for taking time to respond.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s