Writing effective user stories.

1. User Stories
21st Century Requirements

2. your instructor
Derek
Neighbors
derek@integrumtech.com
@dneighbors

3. What Makes a Story?
Card
Stories are traditionally written on note cards and they may be annotated with notes,
estimates, etc.
Conversation
Details behind the story come out during conversations with the product owner.
Confirmation
Acceptance tests confirm the story was coded correctly

4. What Is a Story Card?
Short description of user- or customer-
valued functionality. The visible part of a
story, but the important parts are the
conversations between the customer and

5. Who writes a story card?
The customer team writes the story cards because they
are in the best position to express the desired features
and because they must later be able to work out story
details with developers and to prioritize the stories.
The customer team includes those who ensure that the
software will meet the needs of its intended users. This
may include testers, product manager, real users and
interaction designers.

6. Why User Stories?
Understood equally well by everyone
Useful for iteration planning
Encourage deferring of details
Great for iterative development
Support opportunistic design
Emphasize verbal communication

7. POp Quiz!
1. What are the three parts of a user story?
2.Who is on the customer team?
3.What advantages do requirements
conversations have over requirements
documents?

8. User Story Templates
As a <type of user> In order to <value>
I want to <goal> as a <customer role>
so that <reason> I want <some feature>
As a vacationer,
In order to determine which
I want to see photos of hotel
rooms are the nicest,
rooms,
as a vacationer,
so that I can see which have
I want to see photos of hotels
the nicest rooms

9. What Makes a Good Story?
I Independent
N Negotiable
V Valuable
E Estimatable
S Sized Appropriately
T Testable

10. What Makes a Good Story?
I Independent
Dependencies lead to problems estimating and
prioritizing. Ideally you can work on a single story
without pulling in lots of other stories.

11. What Makes a Good Story?
N Negotiable
Stories are not contracts, they leave (or imply)
some flexibility.

12. What Makes a Good Story?
V Valuable
Valuable to users or customers, not developers.
Rewrite developer stories to reflect value to users
or customers.

13. What Makes a Good Story?
E Estimatable
We need to be able to estimate our user stories so
that we can use them to create a plan.

14. What Makes a Good Story?
S Sized Appropriately
A story is sized appropriately when it can be
completed in one iteration.

15. What Makes a Good Story?
T Testable
You should have an easy and binary way of
knowing when a story is finished. Done or not
done; not partially finished or “done... except...”

16. POP QUIZ!
Find the bad user stories:
The user can run the All graphing and
system on Windows and charting will be done
Linux using a 3rd party library
The soft ware will be The user can undo up to
released on June 30th fifty commands

17. Workshop #1
In teams of 3 to 4 write at least 15 user stories for a
travel website.
20m
Activity Time

18. User Role Modeling
Consider all types of users in a system. Avoid writing
stories from a single perspective by first identifying
different user roles that will interact with the system.
Define relevant attributes for each user role, to better
see the differences between roles. Some roles do well
with a persona, an imaginary representation of a user
role.

19. User Role Modeling Steps
1.Brainstorm an initial set of user roles
2.Organize the Initial Set
3.Consolidate Roles
4.Refine the Roles

20. Refining Roles with Attributes
The frequency with which the user will use the software.
The user’s level of expertise within the domain.
The user’s general level of proficiency with computers
and software.
The user’s level of proficiency with the software being
developed.
The user’s general goal for using the software. Some
users are after convenience, others favor a rich
experience, and so on.

21. User Role Example
User Role: Internal Recruiter
Not particularly computer-sav vy but quite adept at
using the Web. Will use the soft ware infrequently
but intensely. Will read ads from other companies
to figure out how to best word her ads. Ease of use
is important, but more importantly what she learns
must be easily recalled months later.

22. Workshop #2
In teams of 3 to 4 first identify user roles for a travel
website. Next, refine those roles using attributes.
20m
Activity Time

23. How do we gather user stories?
User Interviews
Real users with different roles are best.
What they ask for is not always what
Integrum Tip:
they want Ask open-ended and context-free
questions. “How would you like to
Questionnaires search for jobs?” vs. “Will you
Good for large groups of users but not search for jobs by title?”
a great primary technique
Observation
Helpful for determining how users
interact with existing systems
Story-Writing Workshops
Includes developers, users, customers
and others. Brainstorm to generate as
many stories as possible.

24. Trawling for Requirements
The idea of eliciting and capturing requirements is
wrong. It assumes that we already know all requirements
and that they won’t change.
Instead, think of trawling for requirements. This
acknowledges that requirements are of different sizes
and that they change over time.

25. Workshop #3
In teams of 3 to 5 first designate one team member as
the product owner. Next, run a story workshop for a pet
adoption website.
25m
Activity Time

26. User Proxies
The User’s Manager
May not be appropriate unless they are also a user
Development Managers
Seemingly a good user proxy due to their involvement, but they’re almost never the
intended user
Customers
Best if they are in close communication with the users for whom they are purchasing
the software. Even better if they are also a user
Salespeople
Very helpful if they have contact with a broad variety of customers, but avoid features
that could have won the last lost sale
Domain Experts
Avoid stories that require a user to be at their level of expertise
The Marketing Group
Quality stories vs. Quantity of stories

27. Customer Team
1. Add real users
2. Identify a product champion Integrum Tip:
3. Determine the factors critical to A real user beats a proxy user every
time.
success
What problems might occur when using a proxy user?

28. Workshop #4
In teams of 3 to 5, each team member should choose a
user proxy role. Next, briefly interview each user proxy
using the travel website product. Finally, gather
shortcomings and possible improvements when using
user proxies.
20m
Activity Time

29. Where are the Details?
Does the user get a full
Is confirmation provided
or partial refund? Is it a
to the user? How?
refund or site credit?
As a user, I want to Are the terms different for
members of the frequent
How far ahead must the
reservation be cancelled? cancel a reser vation travelers club?
Is the process the same
How late can the user
for all hotels?
cancel the reservation?

30. Details Added as Smaller STories
As a premium member, I can
cancel a reservation up to
the last minute
As a user, I want to As a non-premium member, I
can cancel a reservation up
cancel a reservation to 24 hours in advance
As a user I am e-mailed a
confirmation when I cancel
a reservation

31. Details as Conditions of Satisfaction
As a user, I want to
cancel a reservation
Conditions of Satisfaction
Verify that a premium member can cancel the same day without a fee
Verify that a premium member is charged 10% for same day cancellation
Verify that an e-mail confirmation is sent
Verify that the hotel is notified of the cancellation

32. Details as Acceptance Criteria
As a VP of Marketing, I
want to see information Integrum Tip:
on television advertising Ensure that your conditions of
when viewing historical satisfaction or acceptance
campaigns acceptance criteria help further
define “done.”
Acceptance Criteria
See how many viewers by age range
See how many viewers by income level
See how many viewers by gender

33. Acceptance Testing
Acceptance tests are used to express the
many details that result from
conversations between customers and
developers.
Other Types of Tests
User interface testing
Usability testing
Performance Testing
Stress Testing

34. User Workflow Scenarios
Integrum Tip:
As a user, I want to
cancel a reservation Draw out simple wireframes to
explain each step in the user
workflow.
When I am viewing my reservation
How far ahead must the
I should see a button to cancel my reservation
reservation be cancelled?
When I click the ‘cancel reservation’ button
I should see a confirmation dialog
When I am viewing my reservation more than 24 hours in advance
...
When I am viewing my reservation less than 24 hours in advance
...

35. Using Given, Then, When
The right details?
Given I am viewing my reservation
As a user, I want to When I click the ‘cancel reservation’ button
cancel a reservation Then I should see a confirmation dialog
Are fewer details better?
Given I am viewing my reservation
When I cancel my reservation
Then I should be prompted to confirm
“If you really care about how the behaviour is implemented, you should probably be
specifying that elsewhere in a more fine-grained story – in other words chunking down
to provide more detail – that won’t be interesting to the audience of this one. If not, you
might want to push the detail down into the implementation of the steps.” - Dan North

36. Acceptance Testing Questions
What else to What am I assuming
programmers need to about how this story
know about this story? will be implemented?
What can the user do As a user, I want to What can go wrong
incorrectly to make this
story not work as cancel a reser vation during the story?
expected?
Are there circumstances
What does the user see
when this story may
during each step of the
behave differently?
story?

37. Workshop #5
In teams of 3 to 5, pick one to two stories from a
previous workshop. Next, generate user workflow
scenarios or given, when, then scenarios for each.
20m
Activity Time

38. Types of User Stories
Story
Story Story
Theme Theme
A collection of related user A collection of related user
Theme Theme
A collection of related user stories A collection of related user stories
Epic
A large user story

39. The Backlog Iceberg
Sprint Story
Story
Release
Theme
A collection of related user
Theme
A collection of related user stories
Future Releases
Epic
A large user story

40. Epics, Themes and Stories
As a VP Marketing, I can select
As a VP Marketing, I want to review
which type of campaigns (dm, t v,
the performance of historical
email, radio, etc) to include when
promotional campaigns so that I can
reviewing the performance of
identify and repeat profitable ones.
historical promotional campaigns.
Epic
Smaller Epic
As a VP Marketing, I want to As a VP Marketing, I want to
see information on direct see information on television
malings when reviewing advertising when reviewing
historical campaigns so that ... historical campaigns so that.....
More Detailed More Detailed

41. Breaking down Epics
As a frequent flyer I As a frequent flyer I
want to check my want to book my trip
account using miles
As a frequent flyer I
want to re-book a
frequent trip
As a frequent flyer I
Frequent Flyer want to book a trip
As a frequent flyer I
want to request an
upgrade
As a frequent flyer I
As a frequent flyer I want to see special
want to... promotions

42. Workshop #6
In teams of 3 to 5, first identify stories from a previous
workshop which are too large. Next, breakdown the
large stories into smaller more fine-grained stories.
20m
Activity Time

43. Tips for Writing good Stories
To identify stories, start by considering the goals of each user role in using the
system.
When splitting a story, try to come up with stories that cut through all layers of the
application.
Create constraint cards and tape to wall or write tests to ensure they are not
violated.
Write smaller stories for functionality that will soon be implemented and broad
stories for functionality further out.
Keep the user interface out of the stories for as long as possible.
When practical, include the user role when writing the story.
Write stories in active voice.
Write stories for a single user.
Have the customer, rather than the developer, write the story.
Keep stories short, and do not forget their purpose as reminders to hold
conversations.
Don’t number stories.

44. Smelly User Stories
Stories are too small
Interdependent stories
Gold plated stories
Too many details
Splitting too many stories
Including user interface details too soon
Thinking too far ahead
Trouble prioritizing
Customer won’t write and prioritize stories

45. Workshop #7
In teams of 3 to 5, first gather stories you’ve generated
from previous workshops. Next, identify good and bad
user stories and note how they differ.
20m
Activity Time