User stories

Credoc

27/11/2012

Lies Van Heddegem

1
 Project execution

Timeboxed iterations
Within the iteration: analysis (for next iteration) +
testing + design + coding + anything else

1 day

 Analysis
 Test
 Design
 Code
 Anything else

Product Sprint Deployable

backlog backlog product

2
 Project execution

Detailed analysis = user stories

1 day

 Analysis
 Test
 Design
 Code
 Anything else

Product Sprint Deployable

backlog backlog product

3
 User stories

What is a user story?

Describes a small piece of functionality (end to end)
Represents business value
Formulated in the customer’s terminology

Example:
As a library employee, I can add
a book to the library catalogue,
so that the library members can
4
borrow this book
 User stories

The user in the user story

Many projects mistakenly assume there’s only one
user: “The user”
Incorporate roles into user stories
 Write the stories from a real user’s perspective
 Software solves needs of real people

Example:
not: A user can add his resume to the
website.
rather: As a job seeker, I can add my
resume to the website, so that…

5
 User stories

A good user story is INVEST

Independent
Negotiable
Valuable
Estimable
Small
Testable

6
 User stories

Independent
Avoid dependencies
Dependencies can lead to problems
Estimation
Prioritization
Planning
But, sometimes hard to achieve!

7
 User stories

Negotiable
Not an explicit contract for features
Discuss user stories! Collaboration needed!
Review/workshop with business, other proxies, developers 
quick feedback

8
 User stories

Valuable
Represents business value to the customer
Each story provides end-to-end functionality (slice the
cake)

9
 User stories

Valuable

10
 User stories

Estimable
Contains just enough information so that the
developers can produce a reasonable estimate

11
 User stories

Small
Small enough to fit in a single iteration (max. 1 pair
during ½ iteration)
Represent 1 business value
Not high and low value in one story

12
 User stories

Small
Split (slice) a user story in case it is too big
Shorter feedback cycle
Risk to forget task is reduced
More focused work
More motivating
Higher accuracy of estimates
Easier to plan
Less unnecessary development

13
 User stories

Small
Split (slice) user stories by 7 dimensions

14

From: Agile Requirements: collaborating to define and confirm needs, E. Gottesdiener

 User stories

Small
Split (slice) user stories by 7 dimensions: functional

What can the user do?

Actions

Who initiates Which business

User role Controls
functionality? rules are there?

Data

Which data is involved? 15

 User stories

Small
Split (slice) user stories by 7 dimensions: non-functional

To users, Quality Performance,

systems, Interface attributes usability,...
Constraints
devices

16
Each product has predefined design and
implementation constraints
 User stories

Small
An epic story is too large (complex or compound) to be
used during development
Split the epic story in user stories

Epic story:
A user can borrow a book
User story:
As a borrower, I can borrow a
normal book, paying with cash,
so that…

17
 User stories

Testable
A user needs to be able to test the user story
Acceptance criteria and test design are added to make
testing easier
To minimize interpretation problems
Definition of done

18
 User stories

When writing user stories?

One sprint before developing
Elaborated just-in-time

19
 User stories

Why writing user stories?

Enables flexibility in planning
Make quick adaptation to change possible
Deliver highest business value first
Respond faster to rapidly changing real-world
requirements
Right size for planning and prioritization
Equally understandable by developers and customers
No large formal requirement documents
Keeps the focus
Based on latest learnings
20
 User stories

A user story is not a use case

User story Use case

Goal: Goal:
Only reason of Permanent artefact
existence is the use in used to document a
the development part of a system
iterations

Scope: Scope:
Smaller Almost always larger
More focused
21
 User stories

How writing user story documents?

Explain more in detail to developers what has to be
built
Elaborate functional HOW
Based on this extra info: agreement with customers
about what is to be built
Keep the document clear, short and to the point
It is a work document, not documentation!

22
 User stories

User story document contains

Story sentence
Acceptance criteria
Context of the story (in bigger picture)
Implementation details
Test design
As a who, I can what, so that why

But also:
-How?
-When?
-More details on who, what and why

23
 User stories

User story document: story sentence

Traditionally written on cards
In active voice , s o tha t w hy
o , I c a n w ha t
As a wh
For one user (WHO)
As a black box wish (WHAT)
Business value is made explicit (WHY)

Example:
not: A resume can be added by a job seeker.
rather: As a job seeker, I can add my resume to the website, in order
to make myself known as a job seeker
Example:
not: Job seekers can remove resumes from the site.
rather: As a job seeker, I can remove my own resume from the24 site, 24
in order to stop making myself known as a job seeker
 User stories

User story documents: acceptance criteria

What?
 Define the boundaries of a story
 Define when the story is ‘done’
 What is the minimal functionality that can provide value?
Other benefits:
 Remove ambiguity from requirements
 Form basis for tests
Not too much criteria:
 Who will read them?

25
 User stories

User story document: acceptance criteria

Story sentence: Acceptance criteria:

As a job seeker, I can add my resume to -A job seeker can only add 1 resume
the website, in order to make myself - A job seeker can add up to keywords
known as a job seeker to his resume
- A job seeker can add his photo to the
resume
- A job seeker can add his resume in
word and pdf format
-...

26
 User stories

User story document: context of story

Explains the purpose of the story in the bigger picture
(module or epic story)

27
 User stories

User story document: implementation details

Tip: Use examples to specify the details
Helps to spot inconsistencies and gaps
Details contains business rules, domain model, paper
prototype (screen design), diagrams, …

28
 User stories

User story document: test design

Tip: write first the test design, afterwards the other
items of the user story document
Helps to spot inconsistencies and gaps
Helps developers to get a better understanding of the
user story
Write down the input and the expected result
ID Input Verwacht resultaat
TC1. De dossierbeheerder bekijkt de kosten Het scherm kosten wordt geopend en geeft een
van een vennootschap. Er zijn overzicht van alle rappelkosten.
rappelkosten.
TC2. De dossierbeheerder bekijkt de kosten De foutmelding ‘Er werden geen kosten gevonden
van een vennootschap. Er zijn geen voor deze vennootschap’ verschijnt.
rappelkosten.
TC3. De dossierbeheerder verwijdert een Eerst wordt er een bevestiging gevraagd. Daarna
rappelkost dat reeds betaald was door wordt de rappelkost verwijderd en afgeboekt. Het
op het vuilbakicoontje te klikken. betaalde bedrag wordt in beraad gezet.
TC4. De dossierbeheerder verwijdert een Eerst wordt er een bevestiging gevraagd. Daarna
rappelkost dat nog niet betaald was wordt de rappelkost verwijderd en afgeboekt. 29
door op het vuilbakicoontje te klikken.
 User stories

User story documents

30
 User stories

User story documents

31
References
[Link]

User Stories Applied For

Agile Software Development
by Mike Cohn

Slicing Requirements for

Agile Succes
by Ellen Gottesdiener & Mary Gorman
in Better Software jul-aug 2010
[Link]

32
References

Telling Stories
by Ben Rinzler

Agile Estimating and Planning

by Mike Cohn

The Software Requirements Memory

Jogger
by Ellen Gottesdiener

33
References

[Link]

Bridging the communication gap

by Gojko Adzic

Agile Testing
by Lisa Crispin en Janet Gregory

34
References

Specification by example
by Gojko Adzic

[Link]

35