WHY is splitting stories properly so important? - This presentation uses an entertaining analogy to illustrate how incremental delivery can be used to help tackle complexity and manage/mitigate various types of risk like technical risk, business risk, delivery risk, etc.

1. © 2016 lukas.klose@agile42.com
This presentation is licensed under Creative Commons Attribution-Share Alike 3.0 Germany License.
Why Split User Stories
or… why incremental delivery is so important

2. Why Split Stories
I know, to make them small…
But to what end?

3. If you were to Build a Road from your Village “A” to
Village “B” Through a Forest...
...how would you break this task
into multiple (like 5) steps…
Village “B”
Village “A”

4. How to build a highway through a forest in 5 years...
Determine how to structure the project
● you are in village “A”... build a highway to village “B” to start trading
● medieval times, so…
● no helicopters
● little to no understanding of the forest (none returned to tell the story)
● 5 roughly equal phases

5. Not a good idea...
● Don’t know what is there until I
survey the landscape
● Might not have enough money to
complete the job
● Project might get cut
prematurely
● Might need to be able to
demonstrate/verify benefits of
getting to village B to get more
funding

6. It’s all About Risk
Management

7. time

8. time

9. Disclaimer
Incremental delivery and splitting user stories is best suited for solving complex
problems (aka unknown unknowns), where high risks justify effort spent on
managing those risks
For simple or merely complicated
Problems with lower risk, incremental delivery
may be more expensive than necessary.

10. Users: explorer
● no infrastructure
● barely enough precedence to
do it once more
● validate assumptions
● get to know people in village B
Step 1 - Blaze a Trail

11. Benefits of Splitting
● Reduce Business Risk
○ proof that it can be done
○ validate business assumptions
○ eg. “do I like the people in ‘village B’”
○ use findings to justify spending more money

12. Step 2 - Harden the Path
Users: foot passenger
● can’t drive, but can walk
with ease
● steady flow of traffic…
validate long term viability
of plans to trade
● sign trade agreement
● small revenue to pay for
project

13. ● Reduce Delivery Risk
○ smaller changes
○ walk before you run
○ identify technical risks with project
○ course correct cheaply based on
learnings
Benefits of Splitting

14. time
smaller stories = higher predictability
eg 4 out of 5 done (=80%) vs. 1 out of 2 (50%)

15. Step 3 - Construct a Road
Users: off road vehicles
● expand the usefulness of the path…
● start light trading with village “B”
(revenue $)
● clear trees and big boulders to allow
paving the road later
● discover technical challenges (like bird
sanctuaries) while still cheap to back
out

16. Benefits of Splitting
● Manage complexity: by attacking bit-size chunks you
can...
○ determine if you have to circumnavigate a bird
sanctuary (aka technical challenge)
○ solve a small part of the problem and learn from it
○ simplify
○ emerge design & architecture
● !! Attack highest complexity items early on while
time is on your side and you still have options !!

17. Step 4 - Harden the Road
Users: most cars and 5-ton
trucks
● start small business
trading with village “B”
(revenue $$)
● pave the path for heavy
duty highway building
equipment
● No edge cases

18. Step 5 - Build a Highway
Users: everyone
● scale solution
● revenue ($$$)

19. It is fully integrated
● encourages teamwork/x-functional
collaboration
● no surprises later
● Integration is complex, so don’t defer it
It provides learnings and stepping stones
● benefits the increments after it
When a Story is Split Well

20. It is valuable
● provides some end-user consumables,
even if very small
● can help produce feedback
When a Story is Split Well

21. When a Story is Split Well
It is shippable/complete
● meets DoD, incl QA
● no need to do further work to ship
● could be feature toggled
● No residual integration risk

22. However
● It could be a fragment of a bigger feature
○ eg. jigsaw puzzle
○ shippable ≠ shipped
○ not useful without other pieces of the puzzle, but has all
layers (cardboard, color, gloss)
● Agile pays a penalty for splitting to gain the
benefits of incremental delivery (risk
management)
○ eg 1 big story = $30k, 5 small stories = $35k
○ product owner pays for this mitigation technique

23. Learning vs Producing
Learn a lot
Produce a lot
Output
Learnings
Learn & Produce

24. Learning vs Producing
consumable
feature Value
Learnings or
foundation or
whatever...

25. Learning vs Producing
end-user consumable
feature
non-user-facing tech
(model/ controller/
services/ DevOps/
etc.) or learnings
(aka spikes)
first few sprints
Vertically
sliced
story
few user facing
features
mostly learning and setting stuff
up (eg “hello world” app)

26. Learning vs Producing
end-user consumable
feature
non-user-facing tech
(controller/ services/
DevOps/ etc.) or
learnings (aka
spikes)
first few sprints
after a few sprints
balance between
evolving/refactoring the tech
stack and delivering
business value
Vertically
sliced
story
Vertically
sliced
story

27. Learning vs Producing
leverage robust tech to
deliver mostly business
value and refactor as
necessary
Vertically
sliced
story
Vertically
sliced
story
Vertically
sliced
story
first few sprints
after a few sprints
mature stage

28. Sinking iceberg
...otherwise called “horizontally split story”: provides no fully
integrated feature directly consumable by the end user. Are you
using waterfall (build now, integrate later)?
Learning vs Producing
Vertically
sliced
story
Vertically
sliced
story
Vertically
sliced
story
first few sprints
after a few sprints
horizontally
sliced story
Mature stage

29. When a Story is Split Well
validate business
viability
validate technical
quality
tackle complexity
deliver working
software=>revenue
validate business
viability
validate technical
quality
tackle complexity
deliver working
software=>revenue
vbv
vyq
tc
dws

31. Techniques
● Split with the team because it’s a technical conversation, and all can learn
● Use acceptance criteria
● Use happy path (subset of use cases)
● Use subset of users
● Use assumptions
● Use constraints
● Use ...

32. Need help with splitting stories?
Have a look at Richard Lawrence’s “splitting user story” cheat sheet:
goo.gl/Y9QUbD

33. Summary
● Splitting stories...
○ reduces risk of different types (business, technical, social, financial, etc)
○ helps attack complex problems one bit at a time
○ helps enter the market early ($ sooner)
○ is a product owner/business concern (business risk mitigation) as much as a
technical concern (complexity and delivery risk mitigation)
● Each story…
○ though very thin, is a fully integrated feature and is consumable by the end
user
○ Is of full quality, fully tested, meets the definition of done
● Further...
○ attack high complexity early on (eg. integration is complex)
○ accept that there is a cost for the benefit of risk management