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

What’s the most
important agile practice?

Slicing is like breathing —
you have to do it, it’s not
a choice

Cutting something into slices (of a chosen
size), each of which independently provides
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
Slicing

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
Distinct from “decomposition”

We need to be able to turn 50 things we think we
need into 10 things we can deliver soon.
Getting quicker to market

We need to be able to turn 50 things we think we
need into 10 things we can deliver soon.
This is only possible if those 10 things deliver
something useful and valuable, and the essence of
what we thought the 50 things would give us.
Getting quicker to market

Create options
Problem solving, research, analysis, design,
learning and responding quickly to new
information within time and budget constraints.
Options can be prioritised,
deferred and rejected

Create focus
(simplest, quickest
path to value)

Create focus
(simplest, quickest
path to value)
Defer / Reject

Collaborative, holistic technique for describing
and narrowing the scope of work up and down
the value chain, with the intent of improving
speed to market and predictability.
The slicing heuristics approach

Collaborative, holistic technique for describing
and narrowing the scope of work up and down
the value chain, with the intent of improving
speed to market and predictability.
The slicing heuristics approach
- Know how often we release useful stuff to customers
by doing it often (Shinkansen)
- Know the scale of endeavours in terms of budget/
time window, objective and needed outcome
- Speed of learning through delivering something
(building confidence in what we are trying to do)
- Speed of feedback from real human beings (via
conversations and observations)

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

XTeams often slice stories
only at the
implementation level.
Not higher up the chain
at the initiative or
capability level.

Rather than slicing and
finding quicker paths to
market, all options
become features in one
big f***-off project
backlog.
BIG F***-OFF PROJECT
Codename: Humungous

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

Not all slicing is made equal.
There are 3 levels of slicing.

1 — CAPABILITY
$$$ MOST VALUE $$$
Customer jobs
aka Problem space
$ LEAST VALUE $

2 — FUNCTIONAL
CUSTOMER
workflow
MOST SOPHISTICATED
(highest schedule risk)
SIMPLEST
(lowest
schedule risk)
Implementation
aka Solution space

3 — TECHNICAL
DEVELOPMENT
workflow
MOST SOPHISTICATED
SIMPLEST
(lowest
schedule risk)
Implementation
aka Solution space

3 — TECHNICAL
DEVELOPMENT
workflow
2 — FUNCTIONAL
CUSTOMER
workflow
1 — CAPABILITY
MOST SOPHISTICATED
SIMPLEST
(lowest
schedule risk)
$$$ MOST VALUE $$$
Implementation
aka Solution space
Customer jobs
aka Problem space
$ LEAST VALUE $

CAPABILITY
What does a CUSTOMER want
to be able to do?
Employ capability slicing patterns to
create deferrable capability options
- Look for seams
- And, or
- Customer types/personas
- User roles
- Target platforms/browsers
- Type/number of products
supported
FUNCTIONAL
What functionality do we need to
implement for the CUSTOMER to
achieve the capability?
Employ functional slicing patterns for
simplest functional solution
- Simplest workflow steps to apply
- Simplest UI/UX
- Zero/one/many
- Business rules
- Happy/unhappy path
- Input options
- 1st X, then the rest
- Data types/parameters
- CRUD operations
TECHNICAL
What tasks or steps do WE
need to take to implement
the functionality?
Employ technical slicing patterns
for simplest technical solution
- Platform technology (e.g.
mobile web vs native app)
- Performance
- Scalability
- Security
- Technical design decisions
GOAL1 2 3 4 5 6

Enable Acme Bank customers to bank with us online

Enable Acme Bank customers to bank with us online
Small business customers
Personal customers
New customers
Homebuyers
Gold credit card holders
School kids
Transfer money between
accounts
Pay bills
Request an overdraft
Apply for a mortgage
Upgrade credit card
Increase credit limit
Desktop website
Android phone
iOS app
Smartwatch
Firefox on iPad
etc. etc.
etc.

Enable Acme Bank customers to pay their bills with BPAY on our website
Select
account
Select
biller
Enter
amount
Enter
transaction
reference
BILL PAID
Submit
payment
info
Receive
verification
code
Enter
verification
code
Confirm
payment
Receive
confirmation
Enter code
manually
Select
from a
dropdown
Search
based on
input
Select
from most/
recently
used
Enter
amount
manually
Enter
reference
manually
No 2FA No 2FA
Receive
code by
email
Receive
code by
SMS
Enter code
manually
Code entered
automatically
See
message on
screen
Receive
email
See
transaction
details
Select
from a
dropdown
Click
submit
button
Click
submit
button

Get user accounts
Get billers
Validate entered biller code
Validate entered amount
Validate payment
2FA - Send verification code
2FA - Validate verification code
SQL query to DB Optimised stored proc
No billers Hardcode billers Billers in txt file All billers from DB User’s billers from DB
No validation Validate code Validation with errors
No validation Validate funds available
No verification Email code SMS code
No validation Manual check Auto check
Dummy API Sandbox API Production API
Validate daily limit
Confirm payment No confirmation On screen message Msg and log Email and log
Select
account
Select
biller
Enter
amount
Enter
transaction
reference
BILL PAID
Submit
payment
info
Receive
verification
code
Enter
verification
code
Confirm
payment
Receive
confirmation
Enable Acme Bank customers to pay their bills with BPAY on our website

An explicit, evolving policy which describes:
A shared language for types of deliverables, their scale and how
they relate to each other (the value chain)
The maximum number of sliced options allowed in a single
deliverable
Success criteria to describe 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 “heuristic”?
Slicing policies need to adapt rather than stay static.
“Method”, “framework” or “process” might not work so well

Example:
• Initiative — Strategic
theme representing business
outcomes
• Capability — Enabled
customer behaviour which is
expected to derive customer
and/or business value as
described by the initiative
• Feature — Product
increment which delivers a
capability
• Story — Explicit user
capability or functionality
served by a feature
1. Define and agree work types

• 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)
2. Agree slicing policy for each work type

• 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
3. Slice work Just-In-
Time

•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
4. Do work and
measure cycle
times

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 policies for work types (where needed, and with a clear hypothesis and experiment)
• Communicate policy changes
• Update work types (only if there is a very good reason)
5. Inspect and adapt policies

• 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
Summary

Thank you!
Questions and
discussion

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

More Related Content

What's hot (20)

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

More from Killick Agile Consulting Services (20)

Recently uploaded (20)

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