WRITING USER STORIES

presented by, Nicholas Cancelliere CSM/CSP

ncancelliere@gmail.com

Background

• Agile since 2003

• Involved in web development for over 11 years

• NTT Communications / Verio

• HomeAway.com

• InCircuit Development Corp

• Certified Scrummaster (CSM) and Scrum Practitioner (CSP)

Personal Objectives

• What is your reason for attending today?

• Who are you?

• What organization do you work for?

• What is your role?

Before We Begin

• No electronics (unless it is an emergency)

• One conversation at a time

• Remember, we learn by our mistakes

• “Parking Lot” discussions that are off-topic

• Restrooms and services

• Anything else, it is your meeting!?

Purpose

To learn how to write user stories, understanding: card, conversation, confirmation. Learn about the INVEST acronym and how to apply it in writing and evaluating user stories.

Approach to Learning

Shuhari: a Japanese martial arts concept describing stages of learning to mastery.

Shu - Follow (success = following technique)

Ha - Break-Away (learn the limits of a technique)

Ri - Fluency (shift techniques by moment, improvise)

What are User Stories?

• How would you describe user stories?

• What are ways projects (traditionally) communicate requirements?

• Why do you think user stories are so popular with Agile software development projects?

The Agile Manifesto

Individual and interactionsover process and tools

Working softwareover comprehensive documentation

Customer collaborationover contract negotiation

Responding to changeover following a plan

User Stories Are...

• a written description (card) used for planning and as a reminder/promise

• note conversations to/which flesh out details

• provide confirmation criteria (to know work is completed)

They Are Not...

• Use Cases

• IEEE (or Detailed) Requirements

• Scenarios

Not Use Cases

• User stories are smaller than use cases

• because they are used to schedule work they cover a smaller scope

• tend to cover a single scenario of a use case (e.g. main success)

Not Use Cases

• Use cases live past the iteration, user stories survive up to the iteration they’re scheduled in

• Use cases tend to include more details (e.g. user interface elements*)

• Use cases usually act to document agreements between dev and customers

• Use cases are a result of analysis activity, while stories initiate analysis conversations

* despite admonishments to avoid this. (Cockburn 2001) This is a bad practice because instead of focusing on user goals we tend to focus on implementation when faced with a user interface preconception.

Use Case Example

Compose and send an e-mail message.

1. User selects the “New Message” menu item.

2. System presents the user with the “Compose New Message” dialog.

3. User edits e-mail body, subject, and recipient(s).

4. User click the “Send” button.4a. User provides no e-mail subject or recipient4b. System cannot connect to mail server

5. System sends the message.

Not IEEE Requirements

Eats, shoots, and leaves.

What am I?

A cowboy in a saloon?

Eats shoots and leaves.

A panda bear?

Not IEEE Requirements

Entrée comes with choice of soup or salad and bread.

Say again?

Soup or (Salad and Bread)

(Soup or Salad) and Bread

Detailed Req. Example

1. The product shall have a gasoline-powered engine.

2. The product shall have four wheels.

a. The product shall have a rubber tire mounted to each wheel.

3. The product shall have a steering wheel.

a. The product shall have a horn on the steering wheel.

4. The product shall have a steel body.

Goal: To make it easy and fast for me to mow my lawn.

(by the way, what do you think this is?)

Not IEEE: Verbalized

• Detailed requirements erroneously assumes that if everything is written down and agreed to then there can be no disagreements

• User stories do not document every last detail, but instead keep a few short sentences to jog our memory of needed conversations

Not IEEE: Comprehensible

• Detailed requirements

• often written in technical jargon unfamiliar to business users or customers

• User stories

• are written using words that everyone can understand

• enable people to recall unstated actions, because of their story nature*

* In the late 70s, a study concluded people were found to be better able to remember events (including actions and inferred actions) if they were organized into stories. (Bower, Black and Tuner 1979)

Not IEEE: Right-sized

• Detailed requirements

• often “sprinkled throughout” a requirements document

• difficult to estimate and prioritize separately

• User stories

• self-contained with everything necessary to be estimated and planned

• easy to estimate and prioritize value

Not IEEE: Iterative Dev

• Detailed requirements

• not optimized for progressive detail

• completism: people feel compelled to fill a form when faced with one

• User stories

• encourage the deferring of details

• have a simple format, no set form

Not IEEE: Opportunistic

• Users don’t know what they want exactly

• We always find things as the system develops

• Even if we could figure it all out ahead of time things change (eg market conditions, user needs)

• As human beings we can comprehend only a limited set of information

• Human beings make mistakes

Not IEEE: Opportunistic

• User stories thrive on opportunity

• do not rely on users knowing exactly everything fully in advance

• do not rely on you comprehending a vast array of details

• most importantly embrace change

Not Scenarios

• Scenarios are typically large and more encompassing than a use case

• too much scope

• too much detail

• Usually you can extract many upon many user stories out of a scenario

Example Scenario

John and his family are thinking about taking a vacation. John doesn’t like hotels, they’re uncomfortable and would prefer to stay in a house. A house would provide at-home amenities and give each family member plenty of personal space. John wants to find a house near the beach and not too far from Disney World, Florida. He enters his search criteria “Disney World Florida beach vacation,” on the homepage. He further refines his search to homes that have 3 bedrooms, a pool and a DVD player. He reviews the remaining selections, checks maps of where they are, and availability. He finds one he likes and books it on-line through the web site.

Why User Stories?

• Emphasize verbal rather than written communication

• Generate tacit knowledge

• Comprehensible by everyone

• Right-sized for planning/estimating

• Work for iterative development

• Encourage participatory design

Writing a Story

• Remember to use language that everyone can understand

• Focus on the user goal (3W’s):

• Who is the user?

• What do they want to do?

• Why do they need to do that?

As a {user} I need/want to {fn} so that/to {biz value}

Example Stories

A buyer can establish an account that remembersshipping and billing information.

As a player I want to cast spells thatheal friendly players I target.

As a user I want to wirelessly use another PC’s drive as a local drive on my PC.

Your Mission Today

Write software for Rosie the Robot:

As a state-of-the-art automated homemaker, Rosie needs your team to develop software that enables her to fulfill this role for the typical family of four with a dog.

Individually create a backlog of 5-8 stories.

Kids can contact Rosie to get a ride home from school.

INVEST

• Individual

• Negotiable

• Valuable

• Estimatable

• Small

• Testable

Individual

• As much as possible avoid dependencies between stories

• When dependencies arise

• Combine the stories into one larger (but independent story)

• Find a different way of splitting them up

• Alternatively put 2 estimates down (one for if the story is done first, or another done after)

Negotiable

• User stories are not contracts or requirements that the software must implement

• Provide the right amount of information

• a phrase or two that act as a conversation reminder

• notes about issues to be resolved

• Details that have been determined through conversation become tests.

Valuable

• Each story must be valued by the users and/or purchasers of the system/software

• Avoid stories only valued by developers

• Best way to make sure they’re valuable is to have the customer write the stories

• User Proxies

• Be aware of biases when using user proxies

Valuable

• Sushi vs Sashimi

Model

Controller

View

Estimatable

• Developers need to be able to take a guess at the size of a story (either in amount of time or effort)

• Reasons developers cannot estimate:

• Developers lack domain knowledge

• Developers lack technical knowledge

• The story is too big (referred to as “epic”)

Spike Story

• Rather than generate a feature (value), these stories generate knowledge/learning

• In XP a “spike” is a brief experiment (usually with throw-away code) to learn just enough to be able to make an estimate

• They are time-boxed “learning” stories, so we are able to put an estimate on them

• Because they are stories the Product Owner has visibility and can prioritize them

Small

• Story size matters

• Too big, they cannot fit into a sprint

• Too small, provide no value to the user

• Compound stories are “epic” stories that can be clearly decomposed into individual stories

• Complex stories that cannot be decomposed and are large because of uncertainty or high complexity -- then use a spike

Epic Story

• Stories that are too large to be accomplished in a single sprint are considered “epic”

• Epic stories can be used as placeholders in your backlog for far-future features

• When planning or working with a story ask, “Is this the level of detail needed for where this story is in the backlog?’

• As epics move up the backlog they decompose into smaller stories until they can be scheduled

Testable

• We need to be able to define what “done” means, through acceptance tests (high-level reminders, promote conversation)

• Focus on ways in which you need to test: Try with expired and bad credit card numbers.

• Common mistake teams make:

• Get overly detailed, “Verify that... verify that...”

• Write obvious tests like “Check spelling.”

Conversation & Confirmation

• Break-up into teams

• One person will play the role of the Product Owner, the rest are team members

• Organize your stories (consolidate and prioritize)

• You need to have 5-8 stories ready for the next planning meeting

Example Story

Kids can contact Rosie to get a ride home from school.

Are pick-ups from after-school activities okay?What about pick-ups off school grounds?

est: med, 6 pts pri: high

Example Story

Try various times (during & after school hrs, weekends).Try contacting by phone.Try contacting by e-mail or sms msg.Try with an emergency over-ride code.Try a pick-up off school grounds. (fail)

Are you INVESTed?

• As a team review your stories.

• Are they INVESTed?

• Rewrite them if necessary.

• Trade them to another team, and let them evaluate them.

Catalog of Story Smells

• Stories are Too Small

• Interdependent Stories

• Goldplating

• Too Many Details

• Including User Interface Detail Too Soon

• Thinking Too Far Ahead

• Splitting Too Many Stories

• Customer Has Trouble Prioritizing

• Customer Won’t Write and Prioritize Stories

“Organic” Example

Web-based Tools

• Mingle (by Thoughtworks Studios)

• RallyDev (by Rally Software)

• VersionOne (by Version One)

• Scrumworks (by Danube Technologies)

Other Topics

• How to handle non-functional requirements?

• Paper or Software?

• User Stories and the User Interface

• Retaining Stories

• Bug Stories

Review

• What did you learn in the past couple of hours?

• Did we cover your “burning question?”

• Retrospect on the Meeting: (+/-)

• What can I learn as a presenter?

• Topics I can cover more fully?

• Other Agile workshops you might want?

Thank You

• You can find a copy of this workshop at:http://www.agileaustin.org

• Useful books:User Stories Applied: For Agile Software Development, by Mike Cohn

• URLs:http://www.scrumalliance.org