The document provides guidance on effectively splitting user stories in agile development, emphasizing the INDEPENDENT, NEGOTIABLE, VALUABLE, ESTIMABLE, SMALL, and TESTABLE (INVEST) criteria for evaluating if stories should be divided. It outlines various patterns and methods for splitting stories, including focusing on roles or operations, identifying variations in business rules, data patterns, and simplifying complexity through vertical slices. Additionally, it includes practical exercises to help teams learn story splitting techniques collaboratively.

1. User Story Splitting
Or how to be the Ninja on splitting
Stories, rather than fruit…
Your Sensei: Paul Boos

2. Master Shifu
Reminds Us…
A story is a….
• Who | What | Why
• As a ____ I would like to ____ so that I can ____
• Role or Persona, ‘Function’, Biz Value

3. The Power of a Story in San 参
Story
Requirement

4. Dragon Stories (aka ‘Epics’)
• Stories that are horrendously large & scare us
• The amount of tasks feel like slaying a beast
• Larger than our iteration
• But even ‘Smaller than
Dragon’ Stories may need
to be split…

5. INVEST
I ndependent – minimize dependencies (to zero
preferably)
N egotiable – ability for Product Owner and
Delivery Team to make trade-offs
V aluable – fulfill end user needs/functionality
E stimable – understood well enough to be
estimated
S mall – fit within a Sprint easily
T estable – have an ability to be verified that they
work

6. Should I Split This Story?
• Does it meet the INVEST Criteria (with
exception of Small)?
No – refactor story first*
• Can it be completed in this Sprint?
No – time to split!
• Will this story consume most of the Team’s
capacity?
Yes – better to split than to be sorry…
* If a story isn’t small it may also be hard to be negotiable, so a story
being both small and negotiable could be exceptions.

7. Don’t
split a story on Waterfall
-like Phases
Unless you like riding very, very large
waves of failure…

8. Useful Considerations
• Story to– one role/persona (generally)
• Story to– one function/task of value
• Vertically slices most of the stack

9. Splitting Kata
• Workflow Steps Pattern
• Operations Pattern
• Business Rule Variations Pattern
• Simple  Complex Pattern
• Variations in Data Pattern
• Mock UI Pattern
• Data Entry Methods Pattern
• Hamburger Method
• Defer Performance Pattern
• Break Out a Spike Pattern 戻る

10. Workflow Steps Pattern
Look for steps in the workflow that chain different
roles/personas together or very distinctly different
functions that can be independently done.
Example: Content Authoring & Approval
• As an author, I want to be able to submit my article, so
that it can be published.
• As an editor, I would like to get notified when an article
has been submitted so that I can review it.
• As an editor, I need to approve an article, so that it can
become visible.
• As an editor, I would like to be able to request more
information, so that I can understand the author’s
intent.

11. Operations Pattern
Focus along Operations (think high level methods or CRUD
type operations).
Example: As a shop keeper I want to manage the products
being sold in my online store so that I can sell what people
want to buy. This could be become:
• As a shop keeper, I want to add and remove products
from my online store, so that I can sell what people want
to buy.
• As a shop keeper, I want to edit product details in my
online store, so that I can avoid recreating a product to
fix a typo … (and so on)
Look for generic verbs such as “manage” or “administer” which hints at multiple
more detailed operations. (Sort of use-case like…)

12. Business Rules Variation Pattern
Find ways to split stories based on business
rules deviations.
Example:
Set Payment Currency
As the buyer, I want to set my currency, so that I can
understand the value.
• Payment currency is set by purchase location
• Payment currency can be pulled from the user profile
• Payment currency defaults to US Dollars
Warning: variations could also be articulating various
acceptance criteria.

13. Simple  Complex Pattern
Look for general stories that hide complexity,
when the definition of the acceptance criteria
uncovers varied ways to approach this, then you
can split along this variance...
Example:
• As a loan applicant, I want to calculate my
mortgage payments
Might be made more specific in ways such as …
• … calculate payments manually
• … using an online spreadsheet template
• … using an online calculator

14. Variations in Data Pattern
Choose data objects that may have variations based
on roles and actions.
Example:
Suppose that there are data objects called Product,
Payment, and Receipt. In this instance, the idea would be
to focus on specific data types for each object type. So
for Product, there might be data types such as Book,
DVD, and Gift Card.
You can then work with the Product Owner to identify
the data type or types with the highest business value
and split the story accordingly.

15. Mock UI Pattern
Create a pretotype/whiteboard of the UI when it
is known to be complex; ID areas where related
functionality is present and story out each area.
Throw away the UI.
Example: Enter a Valid Address:
Street:
City: State: Zipcode:
Find House Value Comparisons:
Select search radius:
5km 10km 25km
Go
Reset
As a potential lendee,
I want to have a correct address,
So that my comparisons are correct.
As a potential lendee,
I want to set the region,
So I can see potential impacts to
my comparisons.
As a potential lendee,
I want to easily reset the data,
So I can easily change comparisons.

16. Data Entry Methods Pattern
Examining various options for data entry at the
UI can be done. Each option is essentially the
same story and thus is a refactoring of a prior
story. Great for identifying MVF options…
Example:
As a user, I can search for flights
between two destinations.
…using simple date input.
…with a fancy calendar UI.

17. Hamburger Method
This method is similar to the prior Data Entry
Methods Pattern. It’s useful when a team thinks
more along technical tasks than user stories.
Example:
Simple
Data
Widget
No Data
Persistence
No Data
Validation
Calendar
Widget
Persist Data
in File
JavaScript
Validation
Pull Date
from
user’s iCall
Persist Data
in RDBMS
Persist Data
in NoSQL DB
Enter
Date
Store data
Validate
Collected
data
Gojko Adzic

18. Defer Performance Pattern
Look for Opportunities to Defer Work for later (and thus
refactor of the code).
“Simplicity--the art of maximizing the amount
of work not done--is essential.”
– Agile Manifesto Principle #10
Example:
Focus on user functionality 1st then various –’ilities’:
Scalability
Performance
Caution:
“Continuous attention to technical excellence
and good design enhances agility.”
– Agile Manifesto Principle #9

19. Break out a Spike Pattern
Often Stories are not necessarily complex, but just have
many unknowns. Turn possible acceptance criteria into
questions and investigate these.
Example: Suppose you didn’t understand how Paypal
worked…
Turn As a seller I want to collect payment with Paypal as it is
universally accepted and this will increase how I get paid.
into…
Spike: How does Paypal work?
How do I know I have a successful payment?
How do I know when a payment is unsuccessful and what options can I
present to the buyer?
Once I answer these I can create a valid story (or set of stories).

20. Helpful Tips for
Splitting Stories
Think in terms of what a user
(role/persona) wants as inputs & outputs.
• What does the user put in? What should or should not
come out?
• What processing should give the output?
• How can we test this?
Think in terms of vertical slices.
• What is the minimal version of this functionality?
• Can you touch all the needed tiers of the system.
Don’t worry about being 100% right…
IKIWISI!

21. Acceptance Criteria
Given context When event Then result
Be the…
Define boundaries of what
is acceptable
Should be specific to story
Results = expectations
Identify specific non-
functional requirements
results

22. Acceptance Criteria Example
• A user cannot submit a form without completing all
the mandatory fields
• Information from the form is retrievable later
• Spam protection is working
• Payment can be accepted as a credit card
• An acknowledgment email is sent to the user after
submitting the form.
As a conference attendee,
I want to be able to register online,
so I can register quickly and cut down on paperwork
(Bullet format)

23. Show Respect
Work with your product owner!
Who else will you negotiate
with..?
Card
Conversation
Confirmation

24. EXERCISES

25. Establish Your Dojo
for exercises 1 - 4
• Gather in groups of 2-4
• Establish who will be the product owner
• Brainstorm stories based on the core
epics or features presented
• Ensure you have acceptance criteria
• Be ready to discuss how you split your
stories
• Feel free to go to a second level

26. Exercise 1
You are building an ecommerce site to sell your
products.
Your Epic:
Browse, Select, and Purchase Products from the
site.
10 Minutes to create stories based on this Epic.
Remember to ID some Acceptance Criteria!
We’ll discuss for 10 minutes

27. Exercise 2
You are building a system to manage content onto
your website.
Your Epic:
Manage Webpages, Images, and Video.
10 Minutes to create stories based on this Epic.
Remember to ID some Acceptance Criteria!
We’ll discuss for 10 minutes

28. Exercise 3
You are building an exercise and diet iPhone
application.
Your Epic:
Generate Anyone’s Exercise Routine and Diet.
10 Minutes to create stories based on this Epic.
Remember to ID some Acceptance Criteria!
We’ll discuss for 10 minutes

29. Exercise 4
Select your largest story for the next Sprint. Your REAL product owner
and SMEs are available to answer questions.
Take 15 minutes to do the following:
Meet INVEST? Except for small, No = refactor
Can we complete in this Sprint? No = split
Will it consume most of the Sprint in effort?
Yes = split
Take 5 minutes to decide on an approach.
Take another 15 minutes to brainstorm stories based on that
approach.
Can you establish some acceptance criteria?
20 minutes to discuss

30. Gather the Buke
for exercises 4 - 5
• Review the stories everyone just created in
the last exercise
• Select 2 stories you think are well constructed;
be able to defend this in terms of INVEST
• We’ll use these for our next 2 exercises as one
group to learn a bit about vertical slicing

31. Exercise 4: Walk the Code Dog
Take 15 minutes to…
Walk through the components of the system
one by one that will change. Draw these out (on
a flip chart or white board).
Did you touch all or most of the layers?

32. Exercise 5: Walk the Dog in the
Component Park
Take 15 minutes to…
Draw the architecture of your system
components on a flip chart or white board.
Using a story you have selected and using a
different color marker, redraw over the
architectural components of the application as
you need to touch them when you implement
the story.

33. For Further Study
Great post on how most teams evolve through their story
understanding by JB Rainsberger
http://www.jbrains.ca/permalink/how-youll-probably-learn-to-split-features
The Hamburger Method by Gojko Adzic
http://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/
Walk the Dog Techniques for Vertical
Storieshttp://www.dhavalpanchal.com/walk-the-dog/
15 ways to split an an Epic (3rd exercise from
here)http://blogs.collab.net/agile/15-ways-to-split-an-epic-a-team-exercise
Beginner’s Guide to Acceptance Criteria (example)
http://www.boost.co.nz/blog/agile/acceptance-criteria/
Derived from Phil Rogers slide deck on Patterns for
Splitting User Stories.

34. You’re a Team
No need to be a solo ninja

35. Let’s go slay
some dragons!
Or better put, slice some stories!