This document discusses techniques for splitting large user stories into smaller stories to facilitate agile development. It begins by explaining why story splitting is needed, such as to improve feature utilization and make stories evaluable and prioritizable. It then provides various methods for how to split stories, such as by workflow steps, business rules, data variations, and performance improvements. Specific examples are given around splitting a flight search story. The overall message is that splitting stories into their simplest independent parts allows for easier implementation, testing, and prioritization in agile development.

1. Splitting your
User Story
庖丁解牛用户故
事
Ali
HP Agile Consultant Services
© Copyright 2011 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice. HP Restricted

2. 姓名: 郑立 （Ali）- HP
敏捷服务培训经验：5年
认证：MBA,CSM,CSP,PMP,ITIL
Agile coaching experience : 5 years
Certification: MBA, CSM, CSP, PMP, ITIL
Email: Aliama0288@gmail.com
Tel: 13761850288
Weibo：http://weibo.com/ali0288
惠普资深敏捷顾问，曾负责并参与惠普中国敏捷流程建设和开发。并不
断对敏捷在惠普中的现状进行改进。
有丰富的团队辅导经验和培训经验，辅导过多个团队进行敏捷式开发。
参与各项敏捷大型活动，并乐与在社区相互分享经验，通过交流学习和
提高敏捷在企业中的应用。
Senior Agile Consultant at HP, used to response for the HP Agile process
building and deployment, and always focus on continuous improvement.
He has rich experience on coaching and trainings, has coached many teams
transfer from traditional to agile.
He is active in many agile events, likes to share the experience with others,
and learn from each other, for the purpose of improve the practical in
enterprise.

3. 上海惠普敏捷咨询团队

4. Objectives
 Project Headaches!
 Why need Spilt?
 How to Split?
• Arrange them
• Split Them

5. Note:

6. Project
Headaches !
Think different!
6 HP Restricted | Date or Rev. #

7. We Built Lots of Stuff we Don’t Use
 One of the biggest costs of traditional development is
overproduction of features
• Must be designed, built and maintained
• Doesn’t get used – provides no value
Feature Usage Rarely or never
Rarely used: 64%
19%
Never
45%
Sometimes
16%
Often or always Often
used: 20% 13% Always
7%
Source: Jim Johnson of the Standish Group at XP2002

8. Things are happening
around us!

9. The Status of Software Project
Value Estimation
Requirement
Defect
Change Employee

10. Why Need Spilt ?
10 HP Restricted | Date or Rev. #

11. Small is to improve the Utilization
from Dean Leffingwell, User Story Primer

12. Small is Evaluable

13. Small is to priorities
3 2
5 4 9 8
User Story A User Story B

14. Small is to priorities
2 3 4 5 8 9
High Medium Low

16. How to Split?
庖丁解牛法
16 HP Restricted | Date or Rev. #

17. User Story Splitting Principle and Purpose
Principle Purpose Cut off the
non-value user
stories
Starts from
most
important user
stories Priorities user
stories
Keep User
story
integrated Easier to
implement and
test

18. Arrange user stories

19. Find out the system backbone and joint

20. Themes - Joint
 Grouping of related items in the product backlog
 Themes act as placeholders for product functionality
EPIC
User
THEME THEME
Story
User User User User User User
Story Story Story Story Story Story

21. Take this for example
 Example: Payment
• Story 1: Pay by Visa Credit Card
• Story 2: Pay by MasterCard
Story 1 Story 2 Story 3
• Story 3: Pay by China Union Pay
 Ways to resolve dependencies… Becomes…
Story 4
1. Combine stories into one larger independent
story (Story 4)
2. Split the stories differently (one credit card,
additional credit cards)
Story 5 Story 6

22. Air tickets booking history list page
We used to: (work follow)
Code
Design Testing Documentation
Implement
Or (architecture )
Database Business
UI Design
Design Logic

23. Splitting in right way
Booking Information View - Theme
User
Age, Passport
Address,
Company
name
Add more
user
Contact
information Informati
on
Search
Cancel
Function User Booking
Name and
1 book
record
Filter
Function
Enhance
Performance
List all book
record

24. Split User Stories
Is your Knife sharp enough now?

25. Cut off the skin
Role type
Relation
Data
ship
Oper status
ation

26. Break the joint
C
o
m
Story A m Story B
o
n

27. Split methods
 Workflow Steps
 Business Rule Variations
 Major Effort/Key Mechanisms
 Simple/Complex
 Variations in Data
 Alternative Interface Options
 Lifecycle of an Entity (CRUD)
 Improving performance or user experience characteristics

28. Simple/Complex
 When the team is discussing a story, and the story seems to be
getting larger and larger (“what about x? - have you
considered y?”), stop and ask “what's the simplest that can
possibly work?” Capture that simple version as its own story,
and then break out all the variations and complexities into
their own stories.
As a traveler, I can search for flights
...specifying a max number of stops
between two destinations…
...including specifying specific airports
...using flexible dates
...specifying flight times
Source: Adapted from Dean Leffingwell, User Story Primer

29. Workflow Steps
 Split the story into steps a user takes to accomplish a
workflow and then implement the workflow in incremental
stages
As an online shopper I want to ...I can select my shipping address
checkout my shopping cart
...I can review and confirm my order
...I can select my payment method
...I can select my shipping method
Source: Adapted from Dean Leffingwell, User Story Primer

30. Improving performance or user experience
characteristics
 Sometimes, the initial implementation isn't all that hard, and
the bulk of the effort relates to making it faster, more reliable,
precise or scalable.
 However, the team can learn a lot from a simple, quick
implementation which unlocks some value for the user
community in the first place. In such cases, break the epic into
successive stories that add improved user experience
characteristics (or “-ilities”).
As a traveler, I can search for flights ...showing a “searching” animation
between two destinations… (slow)
...with results shown within 3 seconds
Source: Adapted from Dean Leffingwell, User Story Primer

31. Are you ready for Split?

32. Thank You
Q&A
©2009 HP Confidential