Some strategies to split user stories.

2. Content
 PBIs (user stories)
 definition, template, examples
 Tips for writing good PBIs (user stories)
 Splitting / Slicing PBIs
 Big Bang / Waterfall
 Agile development
 Horizontal vs. Vertical slicing
 Strategies for Splitting PBIs (User Stories)
 Types of PBIs (User Stories)

3. User Story
 Is a short, simple description of a feature told from the perspective of the
person who desires the new capability, usually a user or customer of the
system:
As a <user, role>, I want < feature, functionality> so that
<benefit>.
1. Who is this functionality for? This is described by the first line: As a <user,
role>. The more specific the user – the better the story
2. What we should create? This is described in the I want < something, feature,
functionality>.
3. Why is it valuable to the user? this is the third part of the story: So that
<benefit, some value is created >
If we don’t know the “who, what, and why”, then we don’t really
understand the story yet. If we don’t understand the story, then we
probably can’t split it.

4. USER STORY – 3Cs
Card: User stories are written on cards. the card has just
enough text to identify the requirement, and to remind
everyone what the story is.
Conversation: The user story is simply a promise to have that
conversation, an ongoing dialogue (customer or user & development
team) that takes place over time, particularly when the story is written,
refined, estimated (release planning, grooming session). The
conversation is mostly verbal but often supplemented by
documentation (UI sketch, notes, reference to other document, etc.)
Confirmation: user stories contain confirmation in the form of
Acceptance Criteria, these detail / clarify the desired behavior. They are
used by the development team to better understand what to build and
test and by the product owner to confirm that the user story has been
implemented to her satisfaction.

5. User Story Card example
User Story Card example as it is used by Agile / XP teams
• User Story statement in the front
• Acceptance criteria in the back
Front
Back

6. Tips for Writing Good User Stories
1 Start with the Users
A PBI (user story) describes how a customer or a user employs the
product. You should therefore tell the stories from the user’s perspective.
2 Use Personas to Discover the Right Stories
A great way to capture your insights about the users and customers is to
use personas. The persona goals help you discover your stories. Simply
ask yourself: What functionality does the product have to provide to meet
the goal of the personas?
3 Write Stories Collaboratively
A PBI (user story) is a communication and collaboration tool. Stories
should never be handed off to the development team. The product
owner and the team should discuss the stories, or even better, write them
together.

7. Tips for Writing Good User Stories
4 Keep your Stories Simple and Concise
Write your PBIs (user stories) so that they are easy to understand. Keep them
simple and concise. Avoid confusing and ambiguous terms, and use active
voice.
5 Start with Epics
Epics (Parent PBIs) are big, coarse-grained user stories (PBIs). Starting with
epics allows you to sketch the product functionality without committing to the
details.
6 Decompose your Stories until they are Ready
Break your epics into smaller, detailed stories until they are ready: clear,
feasible, and testable.
7 Add Acceptance Criteria
Acceptance criteria complement the story’s narrative: They allow you to
describe the conditions that have to be fulfilled so that the story is done

8. User Stories Key Points
 User Stories are relatively small: a few days’ effort for one or a pair of
Team members.
 User Stories are focused on the what (the needs of the user), not the
how (the technology / development).
 User Stories are the starting point for an ongoing collaboration
between the Product Owner and Development Team.
 User stories are best framed in language that users and stakeholders
are familiar with.
 Not everything in the Product Backlog needs to be a User Story.

9. Vertical slicing Vertical vs. Horizontal slicing

14. Compound Stories
 This are Epics comprised of multiple shorter stories
 Often hide a great number of assumptions
 Split compound stories:
 Workflow
 Along operational boundaries
 Data Boundaries
 Business rules
14

15. Complex Stories
 Inherently large not easily disaggregated into
constituent stories  this is rare.
 Some look complex because we don’t know
enough.
 Use a spike to acquire knowledge, then split the
PBI (story) based on the result from the spike
15

16. Strategies for Splitting User Stories
Strategy 1: Split by workflow steps
If user stories involve a workflow of some kind, the item can usually be
broken up into individual steps.
Strategy 2: Split by business rules
Many user stories involve a number of explicit or implicit business rules.
Strategy 3: Split by happy / unhappy flow
Functionality often involves a happy flow and one or more unhappy
flows. The happy flow describes how functionality behaves when
everything goes well. If there a deviations, exceptions or other
problems, unhappy flows are invoked

17. Strategies for Splitting User Stories
Strategy 4: Split by input options / platform
Many web applications have to support various input options and/or
platforms, like desktops, tablets, mobile phones or touch screens
Strategy 5: Split by data types or parameters
Some user stories can be split based on the data types they return or the
parameters they are supposed to handle. e.g. search on web shop
Strategy 6: Split by operations
User stories often involves a number of default operations, such as Create,
Read, Update or Deleted (commonly abbreviated as CRUD). This
operations are very prevalent when functionality involves the management
of entities, such as products, users or orders
Strategy 7: Split by roles
User stories often involves a number of roles (or groups) that performs parts
of that functionality.

18. Strategies for Splitting User Stories
Strategy 8: Split by Acceptance criteria
Split items based on identified acceptance criteria
Strategy 9: Split by test scenarios / test case
This strategy is useful when it is hard to break down large user stories
based on functionality alone. In that case, it helps to ask how a piece of
functionality is going to be tested.
Strategy 10: Break Out a Spike
In some cases, a story may be too large or overly complex, or perhaps
the implementation is poorly understood. In that case, build a technical
or functional spike to figure it out; then split the stories based on that
result

19. Other techniques to Split User Stories
Splitting User Stories with Generic Words
we are looking for a generic or general term in the story which could be
replaced by several more specific terms
Conjunctions and Connectors
read the story looking for connector words such as: and, or, if, when,
but, then, as-well-as, etc.
Splitting User Stories with Timeline Analysis
Ask stakeholders to pretend that the user story is already done, and
then ask “What happens when the functionality gets used? They will
then describe a sequence of events, identify the verifiable steps in the
timeline

20. Types of User Stories (PBIs)