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)

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.

USER STORY – 3Cs

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.

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.

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

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.

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

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.

Vertical slicing Vertical vs. Horizontal slicing

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

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

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

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.

Strategies for Splitting User Stories

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

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

Types of User Stories (PBIs)