Slicing heuristics - Techniques for improving value generation, speed to market and delivery predictability

Neil Killick, 2019, All Rights Reserved
neil_killick neilkillick.com
Slicing
Heuristics
Techniques for improving value
generation, speed to market and
delivery predictability
Neil Killick
⍟ Product development practitioner
⍟ Business, customer and user experience (UX) analyst
⍟ Lean-agile coach and trainer

It is becoming more
common to associate
things the team is
working on with the
value we want to create.
However…

Teams often “slice stories” only
at the implementation level
(functional or technical slicing).
Not much slicing going on
higher up the chain at the
problem or capability level.

Local flow is “good”, but not enough
PROJECT 1
- Milestone 1
- Milestone 2
PROJECT 2
- Milestone 1
- Milestone 2
PROJECT 3
- Milestone 1
- Milestone 2
Progress toward deterministic milestones “Agile teams” trying to improve flow (speed), but
lack optionality and opportunity to change direction

Slicing heuristics, if applied at all
levels, give us a more holistic approach
for combining agility with consistency
and predictability

An explicit, evolving policy which describes for a given
deliverable:
• A shared language for the type of deliverable, its scale and how it relates to
the higher level deliverable (the value chain) 
• How and when to “slice" this deliverable (and when to stop!) 
• Success criteria to ensure the policy is achieving the desired speed to
market and/or level of predictability we require
What is a slicing heuristic?

A heuristic technique (/hjʊəˈrɪstɪk/; Ancient Greek: εὑρίσκω, "find" or
"discover"), often called simply a heuristic, is any approach to problem solving
or self-discovery that employs a practical method, not guaranteed to be optimal,
perfect, logical, or rational, but instead sufficient for reaching an immediate goal.
~ Wikipedia
Why a “heuristic”?
I’m explicitly calling out that the policies need to adapt rather than stay static. “Method”,
“framework” or “process” might not work so well for that purpose.

What is “slicing”?

Cutting something into slices, each of which
independently maintains the essence of the thing being
cut.
e.g. a slice of cake, a slice of apple, a slice of pizza, a
software feature which allows me to accomplish something
What is “slicing”?
Distinct from “decomposition”
Breaking something into distinct pieces, none of which can serve the purpose of
the thing being broken, and all or most of which are required to (re)build it.
e.g. a piece of a Rubik’s Cube, a fuel filter, a broken piece of a glass mirror, a software
component

Agility and flow require SLICING
•Product development involves problem solving, research,
analysis, design, learning and responding quickly to new
information within time and budget constraints. 
•Slicing creates options in terms of problems to be solved
and how to solve them. Options can be prioritised,
deferred and rejected, broken down pieces can’t. 
•Flow of the “right” options is meaningful.

“As a Facebook user, I can share stuff I find
interesting with other people in my life…”
What are the 4 seams (general terms which
we can “slice”)?
Capability Slicing

“As a Facebook user, I can share stuff I find
interesting with other people in my life…”
Slice “Facebook user”, “share”, “stuff I find interesting” and “other people in my
life” (the”seams” in the story): 
“Socialisers” can tell close friends about their Friday night plans
“Town criers” can promote articles to all of their acquaintances
Students can exchange homework tips with their school friends
Family members can share photos with each other
Capability Slicing

Enable Acme Bank customers to bank with us online
Example slices:
• Small business customers can pay their bills with BPAY from their mobile phone
• Large business customers can transfer money between accounts from their
desktop computer
• New customers can request an overdraft from their laptop
• Mortgage customers can apply for a 2nd mortgage from their iPad
• School kids can transfer money between accounts from their Android tablet
• Personal customers can pay their bills with direct deposit from Chrome (latest
version)
• Gold credit card holders can upgrade to platinum from their Apple Watch
• etc….. etc….

1. Define and
agree work types 
Example:
• Initiative — Strategic theme
representing business
outcomes
• Capability — Enabled
customer behaviour which is
expected to derive business
value as described by the
initiative
• Feature — Proposed solution
to deliver a capability
• Story — User capability or
workflow needed to make a
feature

2. Agree slicing policy for each work type
• Define when to stop slicing and create a new card of the same
type 
e.g. with this heuristic, if Jane slices an initiative into 5 capabilities, there are now 2
initiatives — the original one with 3 capabilities and a newly defined one with 2
capabilities 
• Define desired scale (measured in cycle time) and allowed
variation (standard deviation)
• Scale
• How much time / money are we willing to invest to get to market and/or
demonstrate capability / value?
• Defining desired and consistent scale makes portfolio boards extremely useful
— usually we don’t have this because each project or program is based on
deterministic estimates rather than “this is how long we want things to take”
• Variation
• Smaller = better predictability
• Beware — Removing buffers can promote accountability for outcomes and
creative ways to solve problems, but it can also lead to death marches,
depending on how the work is defined and the culture 
• Make policies explicit and visible (HT Kanban Method)

3. Slice work Just-In-Time
• 1 card for each work item coming into the
system, and the slices 
• Conversations between appropriate people
at appropriate cadence for each work type 
• Defer sliced out options (do not include in
“business commitment”) 
• Organise remaining options into appropriate
work types, e.g. push things back upstream

4. Do work and
measure cycle
times
• Different board / cards
for each work type 
• Cadence of e.g. standup
meetings around
different boards to
discuss and add a dot to
represent days / weeks /
months as appropriate

5. Inspect and adapt policies
INSPECT
• Look at actual cycle times, average cycle times and standard deviation across work types
• How long is it taking to deliver work?
• How predictable is our delivery?
• Analyse statistical patterns for work types
• Do we have desired speed to market?
• Do we have desired level of predictability?
• How far off desired state were we? Does it matter? What did we learn?
• Do the work types and policies still make sense?
ADAPT
• Update work types (only if there is a very good reason)
• Update policies for work types (where needed, and with a clear hypothesis and experiment)
• Communicate policy changes

• Work takes longer than desired 
— high cycle time, slow speed to market or delivery to a customer 
• Work is too unpredictable (high variation) within a work type 
— e.g. can’t predict delivery of features for a client 
• Work is too unpredictable at portfolio level 
— e.g. shared capacity planning is too difficult 
• New work types emerges which we need to incorporate 
— e.g. MVP/MMF 
• Work type is retired 
— e.g. move to FDD, no more stories
What might happen?

• Feature cycle time (or variation) is higher than defined limits because:
• Feature definition is not always clear, causing back-and-forth between developers and product owner
• Developers often miss key user scenarios in their testing, causing work to go backwards
• Features are not sliced as thinly as they could be
• Too many features in progress 
• Using our slicing heuristics, we can try to:
• Slice features further for narrower scope, greater simplicity and unambiguity, and explicitly defer them
• Reduce the number of stories allowed in a feature, or features allowed in a capability, or capabilities
allowed in an initiative
• Increase allowable cycle time or variation (if values are at acceptable level) 
• Other experiments we can try:
• Reduce the number of stories / features / capabilities / initiatives allowed in progress
• Create clearer story readiness and done criteria
• Use 3 amigos to clarify all user scenarios and acceptance before development starts
Create hypotheses and experiments

INITIATIVE 1
CURRENT cycle time:
2.2 months
INITIATIVE 2
CURRENT cycle time:
5.1 months
INITIATIVE 3
COMPLETED cycle time:
6.8 months
OPTION 1
OPTION 2
Deferred
OPTION 3
OPTION 4
OPTION 5
Next initiatives
Max capabilities: 3
Max cycle time: 6 months
In flight
INITIATIVE 4
NOT STARTED
Capability
options
DOING DONE
C 2C 3 C 1
C 1 C 2
C 3
C 1 C 2
C 3
C 1 C 2
C 3

CAPABILITY 1
COMPLETED cycle time:
1.8 months
CAPABILITY 2
CURRENT cycle time:
2.2 months
CAPABILITY 3
NOT STARTED
INITIATIVE 1
CURRENT cycle time:
2.2 months
Objectives
• Objective 1
• Objective 2
Key Results
• Key Result 1
• Key Result 2
In flight
Max features: 2
Max cycle time: 2 months
Feature
options
DOING DONE
F 2F 1
F 1
F 2
F 1
F 2
XXXX
Because these are options (from slicing) we can choose to defer them if:
• The capability’s implementation is “good enough” for now
• We have reached a market window or other time/budget constraint
• A higher priority/value capability or initiative needs some more love (capacity)

• Define and agree work types — Agree slicing policy for each work type — Slice work
just-in-time — Do work and measure cycle times — Inspect and adapt policies 
• Use slicing (over decomposition) to create options — far more conducive to meaningful flow and agility
• Slicing heuristics create a focus on slicing which encourages us to be empirical
• Solve problems with minimum effort to meet market windows vs Design a solution, estimate it, build it
• Inspect and adapt both product and process, iterate, remain flexible on our focus, create transparency of effort and
outcomes
• Remove overhead and angst of deterministic estimation rituals and expectations (or use alongside estimates as a safe-
to-fail experiment)
• Emphasis on defining the work in the right way, narrowing scope and steering to outcomes rather than it all depending
on execution 
• Like BDD, the success or otherwise of slicing heuristics depends on whether you treat the conversations
as the most important thing, or the process
Summary

Thank you!
Questions and
discussion

Slicing heuristics - Techniques for improving value generation, speed to market and delivery predictability

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Slicing heuristics - Techniques for improving value generation, speed to market and delivery predictability

Ähnlich wie Slicing heuristics - Techniques for improving value generation, speed to market and delivery predictability (20)

Mehr von Killick Agile Consulting Services

Mehr von Killick Agile Consulting Services (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Slicing heuristics - Techniques for improving value generation, speed to market and delivery predictability