Effective User Stories

User Stories21st Century Requirements

your instructor

DerekNeighborsderek@integrumtech.com@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