User Stories Applied

An Introduction to
User Stories
Mike Cohn - background
Agile c
oach
and tra
Found iner
in
directo g member a
r of Ag nd
and Sc ile
rum Al Alliance
liance
Found
er of M
Goat S o
oftwar untain
e
Ran m
y
projec first Scrum
t back
in 199
Typica 5
l
manag programmer
er etc. to
progre
ssion
© Mountain Goat Software, LLC

What problem do stories address?
• Software requirements is a communication

problem
• Those who want the
software must
communicate with
those who will build
it

Balance is critical
• If either side dominates, the business loses
• If the business side dominates…
• …functionality and dates are mandated with little
regard for reality or whether the developers
understand the requirements
• If the developers dominate…

• …technical jargon replaces the language
of the business and developers lose the
opportunity to learn from listening
Resource allocation
• We need a way of working together so that
resource allocation becomes a shared problem
• Project fails when the problem of resource
allocation falls too far to one side

Responsibility for resource allocation
If developers shoulder the responsibility...
• May trade quality for additional features
• May only partially implement a feature
• May solely make decisions that should involve the
business side
If the business shoulders the responsibility...

• Lengthy upfront requirements negotiation and
signoff
• Features are progressively dropped as the deadline
nears
Imperfect schedules
• We cannot perfectly predict a software
schedule
• As users see the software, they come up with new
ideas
• Too many intangibles
• Developers have a notoriously hard time
estimating
• If we can’t perfectly predict a schedule, we
can’t perfectly say what will be delivered
So what do we do?
We make decisions
based on the ...but do it often
information we have
Rather than making one ...we spread decision-

all-encompassing set of making across the
decisions project
This is
where user stories
come in
S t o r i es A r e
Wh a t

Ron Jeffries’ Three Cs
• Stories are traditionally written
on note cards.
Card
• Cards may be annotated with
estimates, notes, etc.
• Details behind the story come

Conversation out during conversations with
product owner
Confirmation • Acceptance tests confirm the

story was coded correctly
Source: XP Magazine 8/30/01, Ron Jeffries.
Samples from a travel website
As a vacation planner, I
As a user, I want to
want to see photos of the
reserve a hotel room.
hotels.
As a user, I want to As a frequent flyer, I

cancel a reservation. want to rebook a past
trip, so that I save time
booking trips I take
often.

Where are the details?
• As a user, I can cancel a reservation.
• Does the user get a full or partial refund?
• Is the refund to her credit card or is it site credit?
• How far ahead must the reservation be cancelled?
• Is that the same for all hotels?
• For all site visitors? Can frequent travelers cancel later?
• Is a confirmation provided to the user?
• How?

Details as conditions of satisfaction
• The product owner’s conditions of satisfaction can be
added to a story
• These are essentially tests
As a user, I can cancel a

reservation.

Details as conditions of satisfaction
• The product owner’s conditions of satisfaction can be
added to a story
• These are essentially tests
As a user, I can cancel a

reservation. Verify that a premium member can
cancel the same day without a fee.
Verify that a non-premium member is
charged 10% for a same-day
cancellation.
Verify that an email confirmation is
sent.
Verify that the hotel is notified of
any cancellation.

Details added in smaller sub-stories
As a premium site
member, I can cancel
a reservation up to
the last minute.
As a user, I can As a non-premium
cancel a member, I can cancel
reservation. up to 24 hours in
advance.
As a site visitor, I am
emailed a
confirmation of any
cancelled
Techniques can be combined
• These approaches are not mutually exclusive
• Write stories at an appropriate level
• By the time it’s implemented, each story will
have conditions of satisfaction associated with
it

The product backlog iceberg
Sprint
Priority
Release
Future
Releases

The product backlog iceberg
Sprint
Priority
Release
Future
Releases

Stories, themes and epics
User Story
Theme
A description of desired
A collection of related
functionality told from the
user stories.
perspective of the user or
customer.
Epic
A large user story.
An example As a VP Marketing, I want to
select the timeframe to use
when reviewing the
performance of past
promotional campaigns, so
As a VP Marketing, I want to that I can identify and repeat
review the performance of profitable ones.
historical promotional
campaigns so that I can Epics??
identify and repeat profitable
ones. As a VP Marketing, I can select
which type of campaigns
(direct mail, TV, email, radio,
Clearly an epic etc.) to include when
reviewing the performance of
historical promotional
campaigns.
An example
As a VP Marketing, I want to
see information on direct
mailings when reviewing
historical campaigns.
As a VP Marketing, I want to
see information on television
advertising when reviewing
historical campaigns. As a VP Marketing, I want to
see information on email
advertising when reviewing
historical campaigns.

Users
and
Use r Ro le s

“The User”
• Many projects mistakenly assume there’s only
one user:
• “The user”
• Write all stories from one user’s perspective

• Assume all users have the same goals
• Leads to missing stories

Common attributes
Frequent flyer who Wants to schedule
never knows where her family’s annual
she’ll be vacation
Frequent flyer who
flies every week but
always to the same
place
Hotel chain Vice
A frequent flyer’s
President; wants to
assistant; books her
monitor
reservations
reservations

Common attributes
Frequent flyer
Frequent flyer who
always to the same
place
Hotel chain Vice
President; wants to
monitor
reservations
reservations

Common attributes
Frequent flyer
Frequent flyer who
Repeat
always to Traveler
the same
place
Hotel chain Vice
President; wants to
monitor
reservations
reservations

Common attributes
Frequent flyer
Frequent flyer who
Repeat
always to Traveler
the same
Scheduler place
Hotel chain Vice
President; wants to
monitor
reservations
reservations

Common attributes
Infrequent
Frequent flyer who Vacation
Wants Planner
to schedule
Frequent flyer
Frequent flyer who
Repeat
always to Traveler
the same
Scheduler place
Hotel chain Vice
President; wants to
monitor
reservations
reservations

Common attributes
Infrequent
Frequent flyer who Vacation
Wants Planner
to schedule
Frequent flyer
Frequent flyer who
Repeat
always to Traveler
the same
Scheduler place Insider
Hotel chain Vice
President; wants to
monitor
reservations
reservations

User roles
• Broaden the scope from looking at one user
• Allows users to vary by
• What they use the software for
• How they use the software
• Background
• Familiarity with the software / computers
• Used extensively in usage-centered design

Source: Software for Use by
Constantine and Lockwood (1999).
System and programmer users
As the payment
verification system, I
want all transactions to
be well-formed XML.
As a programmer, I
want an API for
deleting widgets from
the database.
Advantages of using roles
Users become Start thinking of software as
tangible solving needs of real people.
Instead we talk about “a

Avoid saying “the
frequent flyer” or “a repeat
user” traveler”
Incorporate “As a <user role>, I want to

roles into stories <goal> so that <benefit>.”

W r i ti ng
Stories

A horrible question
“Would you like it

in a browser?”
• A problem:
• The question is closed
• {Yes | No}

A horrible question
“Would you like it “Of course, now that

in a browser?” you mention it!”
• A problem:
• The question is closed
• {Yes | No}

We can do better
“What would you think of having this app
in a browser rather than as a native
Windows application, even if it means
reduced performance, a poorer overall
user experience, and less interactivity?”
• It’s open
• Full range of answers
• But it has too much context
A better way to ask
“What would you be willing to give up

in order to have it in a browser?”
• We want to ask questions that are

• Open-ended
• Context-free

My context isn’t your context
“Dad, make it warmer.”

My context isn’t your context
“Dad, make it warmer.”
You hear “Increase the temperature.”
“Move the temperature closer

He meant to what we call warm.”
It’s my problem, I know the solution
• Having a problem does not uniquely qualify

you to solve it
• “It hurts when I go like this…”

We need to stop asking users
• Since users don’t know how to solve their
problems, we need to stop asking
• We need to involve them instead
Empirical • Designers of the new system make
decisions by studying prospective
design users in typical situations
Participatory • The users of the system become

part of the team designing the
design behavior of the system
Story-writing workshops
• Includes developers, users, customer, others
• Brainstorm to generate stories
• Goal is to write as many stories as possible
• Some will be “implementation ready”
• Others will be “epics”
• No prioritization at this point

Start with epics and iterate
As a frequent flyer,
I want to see check
my account.
Frequent As a frequent flyer,

I want to book a
flyer trip.
I want to ...

Start with epics and iterate
I want to book a
trip using miles.
I want to see check
my account.
I want to rebook a
Frequent As a frequent flyer, trip I take often.
I want to book a
flyer trip.
I want to request an
As a frequent flyer, upgrade.
I want to ...
I want to see if my
upgrade cleared.
INVEST
in
S to r i e s
Good

What makes a good story?
Independent
Negotiable
Valuable
INVEST
Estimatable
Sized appropriately
Thanks to Bill Wake for the acronym. See
www.xp123.com.
Testable
INVESTing in good stories
• Independent
• Dependenices lead to problems estimating and prioritizing
• Can ideally select a story to work on without pulling in 18
other stories
• Negotiable
• Stories are not contracts
• Leave or imply some flexibility
• Valuable
• To users or customers, not developers
• Rewrite (most) developer stories to reflect value to
users or customers
• Copyright Mountain Goat Software, LLC
INVESTing in good stories
• Estimatable
• Because plans are based on user stories, we need
to be able to estimate them
• Sized Appropriately
• Complex stories are intrinsically large
• Compound stories are multiple stories in one
• Testable
• Stories need to be testable
Copyright Mountain Goat Software, LLC
Us e r S to r i e s
Wh y

1
Stories shift the focus from writing to
talking.
If requirements are then The user will get

written down what she wants

1
talking.

At best she’ll get

what was written

1
talking.

“You built what I

At best she’ll get
asked for, but it’s
what was written
not what I need.”

Words are imprecise
Main dish comes with
soup or salad and bread.
• (Soup or Salad) and Bread

• (Soup) or (Salad and Bread)

Examples
The user can enter a • Must the user enter a
name?
name. It can be 127
• Can it be other than 127
characters. chars?
The system should • What does should mean?

prominently display a • What does prominently
warning message display mean?
whenever the user • Is invalid data defined
enters invalid data. elsewhere?

2
Stories are equally understandable by
developers and customers.
3
Stories support and encourage iterative
development.
4
Stories are the right size for planning.
5
Stories support participatory design.
6
Stories emphasize the user’s goals not
the system’s attributes.
What are we building?

1.The product shall have a gas engine.
2.The product shall have four wheels.
2.1.The product shall have a rubber tire
mounted to each wheel.
3.The product shall have a steering wheel.
4.The product shall have a steel body.
Source: Adapted from The Inmates are
Running the Asylum by Alan Cooper (1999).
What if we had stories instead?
mow my lawn quickly
and easily.
be comfortable while
mowing my lawn.

The product

Most importantly...
Don’t forget the purpose

The story text we write on
cards is less important than
the conversations we have.

Mike Cohn contact info
mike@mountaingoatsoftware.com
www.mountaingoatsoftware.com
(720) 890-6110 (office)
(303) 810-2190 (mobile)

User Stories Applied

Uploaded by

Copyright:

Available Formats

User Stories Applied

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

User Stories Applied

Uploaded by

Copyright:

Available Formats

An Introduction to

© Mountain Goat Software, LLC

• Software requirements is a communication

© Mountain Goat Software, LLC

• If the developers dominate…

© Mountain Goat Software, LLC

If the business shoulders the responsibility...

Rather than making one ...we spread decision-

© Mountain Goat Software, LLC

• Details behind the story come

Confirmation • Acceptance tests confirm the

As a user, I want to As a frequent flyer, I

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

As a user, I can cancel a

© Mountain Goat Software, LLC

As a user, I can cancel a

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

• Write all stories from one user’s perspective

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

• Used extensively in usage-centered design

Instead we talk about “a

Incorporate “As a <user role>, I want to

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

“Would you like it

© Mountain Goat Software, LLC

“Would you like it “Of course, now that

© Mountain Goat Software, LLC

“What would you be willing to give up

• We want to ask questions that are

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

You hear “Increase the temperature.”

“Move the temperature closer

• Having a problem does not uniquely qualify

© Mountain Goat Software, LLC

Participatory • The users of the system become

• No prioritization at this point

© Mountain Goat Software, LLC

Frequent As a frequent flyer,

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

© Mountain Goat Software, LLC

If requirements are then The user will get

© Mountain Goat Software, LLC

If requirements are then The user will get

At best she’ll get

© Mountain Goat Software, LLC