2007-10-01 Mike Cohn - User Stories Applied PDF

An Introduction to User Stories
Mike Cohn - background

directo g member a nd r of Ag ile and Sc rum Al Alliance liance Found er of M o Goat S oftwar untain e Ran m y projec first Scrum t back in 199 5 Typica l manag programmer er etc. to progre ssion
Mountain Goat Software, LLC
Agile c oach and tra iner Found in
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 technical jargon replaces the language of the business and developers lose the opportunity to learn from listening
If the developers dominate
Resource allocation
We need a way of working together so that Project fails when the problem of resource
allocation falls too far to one side resource allocation becomes a shared problem
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 cant perfectly predict a schedule, we

cant perfectly say what will be delivered
So what do we do?
We make decisions based on the information we have Rather than making one all-encompassing set of decisions
...but do it often
...we spread decisionmaking across the project
This is where user stories come in

e r A s e i r o t S t a Wh
Ron Jeffries Three Cs

Card
on note cards. Cards may be annotated with estimates, notes, etc.
Stories are traditionally written
Conversation
Details behind the story come

out during conversations with product owner story was coded correctly
Conrmation
Acceptance tests conrm the

Source: XP Magazine 8/30/01, Ron Jeffries.
Samples from a travel website

As a user, I want to reserve a hotel room.
As a vacation planner, I want to see photos of the hotels. As a frequent flyer, I want to rebook a past trip, so that I save time booking trips I take often.
As a user, I want to cancel a reservation.
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? Is that the same for all hotels? For all site visitors? Can frequent travelers cancel later? How?
How far ahead must the reservation be cancelled?
Is a conrmation provided to the user?
Details as conditions of satisfaction
The product owners conditions of satisfaction can be added to a story
These are essentially tests
Details as conditions of satisfaction
The product owners conditions of satisfaction can be added to a story
These are essentially tests

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 non-premium member, I can cancel 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 its 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

Theme
A collection of related user stories.
User Story
A description of desired functionality told from the perspective of the user or customer.
Epic
A large user story.
An example
As a VP Marketing, I want to review the performance of historical promotional campaigns so that I can identify and repeat protable ones.
Clearly an epic
As a VP Marketing, I want to select the timeframe to use when reviewing the performance of past promotional campaigns, so that I can identify and repeat protable ones.
Epics??
As a VP Marketing, I can select which type of campaigns (direct mail, TV, email, radio, 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 s e l o R r Use
The User
Many projects mistakenly assume theres only
one user:
Write all stories from one users perspective Assume all users have the same goals Leads to missing stories
The user
Common attributes
Frequent yer who Wants to schedule never knows where her familys annual shell be vacation Frequent yer who ies every week but always to the same place Hotel chain Vice A frequent yers President; wants to assistant; books her monitor reservations reservations
Common attributes
Frequent yer who Wants to schedule never knows where her familys annual shell be vacation Frequent yer Frequent yer who ies every week but always to the same place Hotel chain Vice A frequent yers President; wants to assistant; books her monitor reservations reservations
Common attributes
Frequent yer who Wants to schedule never knows where her familys annual shell be vacation Frequent yer Frequent yer who ies every week but always to Traveler the same Repeat place Hotel chain Vice A frequent yers President; wants to assistant; books her monitor reservations reservations
Common attributes
Frequent yer who Wants to schedule never knows where her familys annual shell be vacation Frequent yer Frequent yer who ies every week but always to Traveler the same Repeat Scheduler place Hotel chain Vice A frequent yers President; wants to assistant; books her monitor reservations reservations
Common attributes
Frequent yer who never knows where her familys annual shell be vacation Frequent yer Frequent yer who ies every week but always to Traveler the same Repeat Scheduler place Hotel chain Vice A frequent yers President; wants to assistant; books her monitor reservations reservations
Infrequent Vacation Planner Wants to schedule
Common attributes
Frequent yer who never knows where her familys annual shell be vacation Frequent yer Frequent yer who ies every week but always to Traveler the same Repeat Scheduler Insider place Hotel chain Vice A frequent yers President; wants to assistant; books her monitor reservations reservations
Infrequent Vacation Planner Wants to schedule
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 tangible Avoid saying the user Incorporate roles into stories
Start thinking of software as solving needs of real people. Instead we talk about a frequent yer or a repeat traveler As a <user role>, I want to <goal> so that <benet>.
g n i t i r W 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 in a browser?
Of course, now that 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?
Its open But it has too much context

Full range of answers
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 isnt your context

Dad, make it warmer.
My context isnt your context

Dad, make it warmer.
You hear He meant
Increase the temperature. Move the temperature closer to what we call warm.
Its 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 dont know how to solve their
problems, we need to stop asking
Empirical design Participatory design
We need to involve them instead
Designers of the new system make

decisions by studying prospective users in typical situations
The users of the system become

part of the team designing the 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 No prioritization at this point
Some will be implementation ready Others will be epics
Start with epics and iterate

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

As a frequent flyer, I want to see check my account. As a frequent flyer, I want to book a trip using miles. As a frequent flyer, I want to rebook a trip I take often. As a frequent flyer, I want to request an upgrade. As a frequent flyer, I want to see if my upgrade cleared.
Frequent flyer
As a frequent flyer, I want to book a trip.
As a frequent flyer, I want to ...
INVEST in s e i r o t S Good
What makes a good story?

Independent Negotiable
INVEST
Valuable 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 Stories are not contracts Leave or imply some exibility
Negotiable
Valuable To users or customers, not developers Rewrite (most) developer stories to reect 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 Testable
Complex stories are intrinsically large Compound stories are multiple stories in one Stories need to be testable
Copyright Mountain Goat Software, LLC
s e i r o t S r e s U y Wh
Stories shift the focus from writing to talking. The user will get what she wants
If requirements are written down
then
Stories shift the focus from writing to talking. The user will get what she wants At best shell get what was written
then
Stories shift the focus from writing to talking. The user will get what she wants At best shell get what was written

You built what I asked for, but its not what I need.
then
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 name. It can be 127 characters.
Must the user enter a
name? Can it be other than 127 chars?
The system should prominently display a warning message whenever the user enters invalid data.
What does should mean? What does prominently

display mean? Is invalid data dened elsewhere?
Stories are equally understandable by developers and customers. Stories support and encourage iterative development. Stories are the right size for planning. Stories support participatory design.
4 5
Stories emphasize the users goals not the systems 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?

As a user, I want to mow my lawn quickly and easily. As a user, I want to be comfortable while mowing my lawn.
The product
Most importantly...
Dont forget the purpose The story text we write on cards is less important than the conversations we have.
Mike Cohn contact info

[email protected] www.mountaingoatsoftware.com (720) 890-6110 (ofce) (303) 810-2190 (mobile)

2007-10-01 Mike Cohn - User Stories Applied PDF

Uploaded by

Copyright:

Available Formats

2007-10-01 Mike Cohn - User Stories Applied PDF

Uploaded by

Document Information

Original Title

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

2007-10-01 Mike Cohn - User Stories Applied PDF

Uploaded by

Copyright:

Available Formats

An Introduction to User Stories

Mike Cohn - background

Agile c oach and tra iner Found in

What problem do stories address?

Software requirements is a communication

Mountain Goat Software, LLC

If the developers dominate

Mountain Goat Software, LLC

Responsibility for resource allocation

If the business shoulders the responsibility...

Lengthy upfront requirements negotiation and

signoff Features are progressively dropped as the deadline nears

If we cant perfectly predict a schedule, we

...we spread decisionmaking across the project

This is where user stories come in

Mountain Goat Software, LLC

Ron Jeffries Three Cs

Stories are traditionally written

Details behind the story come

Acceptance tests conrm the

Source: XP Magazine 8/30/01, Ron Jeffries.

Samples from a travel website

As a user, I want to cancel a reservation.

Mountain Goat Software, LLC

Where are the details?

How far ahead must the reservation be cancelled?

Is a conrmation provided to the user?

Details as conditions of satisfaction

The product owners conditions of satisfaction can be added to a story

These are essentially tests

As a user, I can cancel a reservation.

Mountain Goat Software, LLC

Details as conditions of satisfaction

The product owners conditions of satisfaction can be added to a story

These are essentially tests

As a user, I can cancel a reservation.

Details added in smaller sub-stories

As a user, I can cancel a reservation.

Techniques can be combined

have conditions of satisfaction associated with it

Mountain Goat Software, LLC

The product backlog iceberg

Release Future Releases

The product backlog iceberg

Release Future Releases

Stories, themes and epics

Mountain Goat Software, LLC

Users and s e l o R r Use

Mountain Goat Software, LLC

Infrequent Vacation Planner Wants to schedule

Mountain Goat Software, LLC

Infrequent Vacation Planner Wants to schedule

Mountain Goat Software, LLC

Used extensively in usage-centered design

System and programmer users

Advantages of using roles

Mountain Goat Software, LLC

The question is closed

Mountain Goat Software, LLC