Effective User Stories
-
Upload
derek-neighbors -
Category
Technology
-
view
19 -
download
1
description
Transcript of Effective User Stories
User Stories21st Century Requirements
your instructor
[email protected]@dneighbors
What Makes a Story?
ConversationDetails behind the story come out during conversations with the product owner.
CardStories are traditionally written on note cards and they may be annotated with notes, estimates, etc.
ConfirmationAcceptance tests confirm the story was coded correctly
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
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.
Why User Stories?
Emphasize verbal communication
Understood equally well by everyone
Useful for iteration planning
Great for iterative development
Encourage deferring of details
Support opportunistic design
Emphasize verbal communication
Understood equally well by everyone
Useful for iteration planning
Great for iterative development
Encourage deferring of details
Support opportunistic design
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?
User Story Templates
As a <type of user>I want to <goal>so that <reason>
In order to <value>as a <customer role>I want <some feature>
As a vacationer,I want to see photos of hotel rooms,so that I can see which have the nicest rooms
In order to determine which rooms are the nicest,as a vacationer,I want to see photos of hotels
What Makes a Good Story?
I
N
V
E
S
T
Independent
Negotiable
Valuable
Estimatable
Sized Appropriately
Testable
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.
What Makes a Good Story?
Stories are not contracts, they leave (or imply) some flexibility.
N Negotiable
What Makes a Good Story?
Valuable to users or customers, not developers. Rewrite developer stories to reflect value to users or customers.
V Valuable
What Makes a Good Story?
We need to be able to estimate our user stories so that we can use them to create a plan.
E Estimatable
What Makes a Good Story?
A story is sized appropriately when it can be completed in one iteration.
S Sized Appropriately
What Makes a Good Story?
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...”
T Testable
POP QUIZ!
The user can run the system on Windows and Linux
All graphing and charting will be done using a 3rd party library
The user can undo up to fifty commands
The software will be released on June 30th
Find the bad user stories:
Workshop #1
In teams of 3 to 4 write at least 15 user stories for a travel website.
20mActivity Time
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.
User Role Modeling
User Role Modeling Steps
1.Brainstorm an initial set of user roles
2.Organize the Initial Set
3.Consolidate Roles
4.Refine the Roles
Refining Roles with AttributesThe 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.
User Role Example
User Role: Internal RecruiterNot particularly computer-savvy but quite adept at using the Web. Will use the software 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.
Workshop #2
In teams of 3 to 4 first identify user roles for a travel website. Next, refine those roles using attributes.
20mActivity Time
How do we gather user stories?User Interviews
Real users with different roles are best. What they ask for is not always what they want
QuestionnairesGood for large groups of users but not a great primary technique
ObservationHelpful for determining how users interact with existing systems
Story-Writing WorkshopsIncludes developers, users, customers and others. Brainstorm to generate as many stories as possible.
Integrum Tip:Ask open-ended and context-free questions. “How would you like to search for jobs?” vs. “Will you search for jobs by title?”
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.
Trawling for Requirements
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.
25mActivity Time
User ProxiesThe User’s Manager
May not be appropriate unless they are also a user
Development ManagersSeemingly a good user proxy due to their involvement, but they’re almost never the intended user
CustomersBest if they are in close communication with the users for whom they are purchasing the software. Even better if they are also a user
SalespeopleVery helpful if they have contact with a broad variety of customers, but avoid features that could have won the last lost sale
Domain ExpertsAvoid stories that require a user to be at their level of expertise
The Marketing GroupQuality stories vs. Quantity of stories
Customer Team1. Add real users2. Identify a product champion3. Determine the factors critical to
success
Integrum Tip:A real user beats a proxy user every time.
What problems might occur when using a proxy user?
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.
20mActivity Time
Where are the Details?
As a user, I want to cancel a reservation
Is confirmation provided to the user? How?
Does the user get a full or partial refund? Is it a
refund or site credit?
How far ahead must the reservation be cancelled?
Is the process the same for all hotels?
Are the terms different for members of the frequent
travelers club?
How late can the user cancel the reservation?
Details Added as Smaller STories
As a user, I want to cancel a reservation
As a premium member, I can cancel a reservation up to the last minute
As a non-premium member, I can cancel a reservation up to 24 hours in advance
As a user I am e-mailed a confirmation when I cancel a reservation
Details as Conditions of Satisfaction
As a user, I want to cancel a reservation
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
Conditions of Satisfaction
Details as Acceptance CriteriaAs a VP of Marketing, I want to see information on television advertising when viewing historical campaigns
See how many viewers by age range
See how many viewers by income level
See how many viewers by gender
Acceptance Criteria
Integrum Tip:Ensure that your conditions of satisfaction or acceptance acceptance criteria help further define “done.”
Acceptance Testing
Acceptance tests are used to express the many details that result from conversations between customers and developers.
User interface testingUsability testingPerformance TestingStress Testing
Other Types of Tests
User Workflow Scenarios
As a user, I want to cancel a reservation
When I am viewing my reservationI should see a button to cancel my reservationWhen I click the ‘cancel reservation’ button
I should see a confirmation dialog
How far ahead must the reservation be cancelled?
When I am viewing my reservation more than 24 hours in advance...
When I am viewing my reservation less than 24 hours in advance...
Integrum Tip:Draw out simple wireframes to explain each step in the user workflow.
Using Given, Then, When
As a user, I want to cancel a reservation
Given I am viewing my reservationWhen I click the ‘cancel reservation’ buttonThen I should see a confirmation dialog
The right details?
Given I am viewing my reservationWhen I cancel my reservationThen I should be prompted to confirm
Are fewer details better?
“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
Acceptance Testing Questions
As a user, I want to cancel a reservation
What else to programmers need to know about this story?
What am I assuming about how this story
will be implemented?
What can the user do incorrectly to make this
story not work as expected?
Are there circumstances when this story may behave differently?
What can go wrong during the story?
What does the user see during each step of the
story?
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.
20mActivity Time
Types of User Stories
EpicA large user story
ThemeA collection of related user stories
ThemeA collection of related user stories
ThemeA collection of related user
ThemeA collection of related user
Story Story
Story
The Backlog Iceberg
EpicA large user story
ThemeA collection of related user stories
ThemeA collection of related user
Story
StorySprint
Release
Future Releases
Epics, Themes and Stories
As a VP Marketing, I want to review the performance of historical promotional campaigns so that I can identify and repeat profitable ones.
Epic
As a VP Marketing, I can select which type of campaigns (dm, tv, email, radio, etc) to include when reviewing the performance of historical promotional campaigns.
Smaller Epic
As a VP Marketing, I want to see information on direct malings when reviewing historical campaigns so that ...
More Detailed
As a VP Marketing, I want to see information on television advertising when reviewing historical campaigns so that.....
More Detailed
Breaking down Epics
Frequent Flyer
As a frequent flyer I want to check my account
As a frequent flyer I want to book a trip
As a frequent flyer I want to...
As a frequent flyer I want to book my trip using miles
As a frequent flyer I want to re-book a frequent trip
As a frequent flyer I want to request an upgrade
As a frequent flyer I want to see special promotions
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.
20mActivity Time
Tips for Writing good StoriesTo 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.
Smelly User Stories
Stories are too smallInterdependent storiesGold plated storiesToo many detailsSplitting too many storiesIncluding user interface details too soonThinking too far aheadTrouble prioritizingCustomer won’t write and prioritize stories
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.
20mActivity Time