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. The Slicing Heuristic seeks 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 based on the hypothesis that empiricism leads to smaller cycle time duration and variation (which in business value terms means quicker time to market and better predictability) because it requires work to be sliced into clear, simple, unambiguous goals. Crucially, the heuristic also describes success criteria to ensure it is achieving the level of predictability we require. Its application is most effective when used for all levels of work, but can certainly be used for individual work types. For example, a User Story heuristic can be an extremely effective way of creating smaller, simpler work increments, allowing teams to provide 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.

1. Neil Killick, Portfolio Manager
neilkillick.com neil2killick@gmail.com @neil_killick
Slicing for
Organisational Agility
using
The Slicing Heuristic
A #NoEstimates Method for
Faster & More Predictable Delivery
Copyright Neil Killick, 2015

2. Not another story slicing talk!

5. FAST
Shinkansen trains can reach speeds of up to 320km/h
PREDICTABLE
13 trains per hour between Tokyo & Osaka (train every 3-5 mins)
In 2014, avg delay was 54 seconds, including uncontrollable causes
such as natural disasters
RELIABLE
5 billion passengers, 150 million per year

6. How did they do it?
❏ Built dedicated lines for high speed rail, so
not slowed down by slower trains
❏ No road crossings
❏ Specially designed tracks

7. You can’t just make a train faster
or more reliable.
You must create a network for
fast, reliable trains.

8. Agile is ordering tapas til you’re full,
not ordering a 10-course meal.

9. Is Agile
Estimation
really
helping us?
❏ Predictive
❏ Optimised for speed
❏ Points are abstract
❏ Focused on cost
❏ Developer-centric
❏ False sense of security

10. So, What is a Slicing
Heuristic?
❏ An explicit policy that describes how to "slice"
work to help us achieve:
❏ Faster time to market*
❏ Better predictability**
❏ How?
❏ Define work with a consistent & shared language
❏ Replace deterministic estimation rituals with:
❏ Slicing rituals
❏ Empirical measurement of actual cycle times for all work types

11. slicing
…[creating] relatively thin, broad piece[s] cut from an object
having some bulk or volume…
[ref: yourdictionary.com]
heuristic
...any approach to problem solving, learning, or discovery that
employs a practical methodology not guaranteed to be optimal
or perfect, but sufficient for the immediate goals.
[ref: Wikipedia]

12. How To: 5-step cycle
1. Define & agree work types
2. Agree slicing policy for each
work type
3. Slice work, Just-In-Time
4. Do work + measure
cycle times
5. Inspect & adapt policies
Initiative
Capability
Feature
Story
Build
Slice
Measure
Learn

13. 1. Define & agree work
types - An example
❏ Initiative - Strategic theme, likely to last several
months or longer
❏ Capability - Desired customer outcome, likely to
last several iterations
❏ Feature - Proposed solution to deliver a capability,
likely to last a few weeks
❏ Story - User capability needed to make a feature,
likely to last a few days

14. 2. Agree
slicing
policy
for each
work
type
❏ Define when to stop
slicing
❏ State desired cycle time
& variation
❏ Make policies explicit &
visible (HT Kanban
Method)
Initiative
Capability
Feature
Story
❏ Max 3 Capabilities
❏ Cycle time < 6 months
❏ Std dev < 3 weeks
❏ Max 2 Features
❏ Cycle time < 2 months
❏ Std dev < 6 days
❏ Max 4 Stories
❏ Cycle time < 2 weeks
❏ Std dev < 3.5 days
❏ 1 Acceptance Test
❏ Cycle time < 3 days
❏ Std dev < 0.5 days

15. 3. Slice work
Just-In-Time
❏ 1 card for each work item coming into the system
❏ Conversations between appropriate people at appropriate
cadence for each work type
❏ Remove/de-prioritise options
❏ Organise remaining options into appropriate work types
e.g. push things back upstream

16. Initiative
Capability 1 Capability 2 Capability 3
Feature
1
Feature
2
Feature
1
Feature
2
Feature
1
Feature
2
Story
1
Story
2
Story
3
Story
4
Story
1
Story
2
Story
1
Story
3
Story
2
Story
2
Story
1
Story
1
Story
3
Story
2
Story
4
Story
1
Story
3
Story
2

17. To Do Doing Done
= 1 elapsed day
Easy to add a dot
at daily standup,
or just update
the data daily in
a spreadsheet
Story 1 Story 2 Story 3 Story 4 Story 5
Elapsed days 2 3 1 1 2
Days
Stories
We need
this data!
4. Do work + measure
cycle times

18. 5. Inspect & adapt
policies
❏ How long is it taking to deliver work?
❏ Analyse statistical patterns for work types
❏ Do we have desired speed to market?
❏ Do we have desired level of predictability?

19. What might happen?
1. Work takes longer than desired (high cycle time)
2. Work is unpredictable overall (high variation)
3. Work is unpredictable within a work type
4. New work types emerge
❏ e.g. MVP/MMF
5. Work type is retired
❏ e.g. move to FDD, no more stories

20. High Cycle Time
We can try...
❏ Creating clearer story definition &/or acceptance criteria (Definitions of Ready
& Done)
❏ Better acceptance tests upstream to clarify all user scenarios, e.g. 3 Amigos
❏ Slicing work more ruthlessly for simplicity and unambiguity
❏ Reducing WIP at one or more levels
Leading to:
❏ Simpler stories, more options & lower risk
❏ Shorter feedback loops for faster learning & delivery of customer value
❏ Reduced delays such as hand-offs, story defects, other queues &
dependencies on people outside of the team

21. Variable Cycle Time
We can try...
❏ Being more consistent in the way work is defined & broken down
❏ Keeping WIP consistent
❏ Minimising distractions
Leading to…
❏ Managers can use empirical data for more predictable delivery
forecasting, rather than relying on crystal ball gazing by the team
❏ Reduced stress on the team
❏ Increased transparency & trust with stakeholders

22. Benefits
❏ Empirical
❏ Optimised for
conversations
❏ Time is a universal unit
❏ Promotes collaboration
“up the chain”
❏ Build the right
thing (right
solution for right
problem)
❏ Control risk
(cost/schedule)
Initiative
Capability
Feature
Story
❏ Max 3 Capabilities
❏ Cycle time < 6 months
❏ Std dev < 3 weeks
❏ Max 2 Features
❏ Cycle time < 2 months
❏ Std dev < 6 days
❏ Max 4 Stories
❏ Cycle time < 2 weeks
❏ Std dev < 3.5 days
❏ 1 Acceptance Test
❏ Cycle time < 3 days
❏ Std dev < 0.5 days

23. *Faster time to
market
❏ Slicing makes work simple & unambiguous - naturally
leads to “small”
❏ Slicing reduces risk
❏ Slicing exposes options that we can throw away or delay
So, making slicing an explicit, measurable activity across our
portfolio is likely to increase speed to market.

24. **Better
predictability
❏ Work at all levels can be forecast using empirical data
❏ Makes portfolio views extremely useful
❏ Instantly know that e.g. a feature is 2-4 weeks
❏ Collaboration & quality of conversations are improved
So, making slicing an explicit, measurable activity across our
portfolio is likely to increase predictability.

25. All we need is a continuous
improvement mindset.
And a method.

26. Build
Slice
Measure
Learn
1. Define & agree work types
2. Agree slicing policy for each work
type
3. Slice work, Just-In-Time
4. Do work + measure cycle times
5. Inspect & adapt policies

27. DISCLAIMER
This will only work if you try it.

28. Neil Killick, Portfolio Manager
neilkillick.com neil2killick@gmail.com @neil_killick
Copyright Neil Killick, 2015