User Stories

User Stories
An Introduction

Prof. David Bernstein
James Madison University

Computer Science Department

bernstdh@jmu.edu

Overview

What are they?
- A format for expressing "desired business value" (a.k.a, features, requirements)
Where are they used?
- Represent product backlog items and/or sprint backlog items in Scrum
Who is the audience?
- "Business" people
- "Technical" people
What are the components?
- Card
- Conversation
- Confirmation

Cards

Template:
- Title
- The class of users (i.e., the role of users)
- What the users want (i.e., the goal)
- Why the users want the goal (i.e., the benefit)
Format:
- The title appears at the top of the card
- The story is written in paragraph form (i.e., As a role I want to goal so that benefit)
Purpose:
- A "placeholder for"/"promise to conduct" more detailed conversations

Conversation

Confirmation

Defined:
- Conditions of satisfaction (i.e., acceptance criteria that clarify the desired behavior)
Uses:
- Development Team - better understand what to build and test
- Product Owner - validation
Form/Format:
- Usually a checklist on the back of the card
- Usually textual descriptions that describe what the product did during the Sprint Review (sometimes in the "As a stakeholder, when I action then the system criterion" format)
- Must be atomic
- Must not use vague/ambiguous/subjective language that could be subject to debate

Appropriate Level of Detail/Abstraction

From Stories to Tasks

Stories:
- Are requirements of the product (i.e., the product must do...)
Tasks:
- Are actions to be completed (typically in a few hours or less) by the team (i.e., a person must do...) in order to realize a story

Tasks vs. Acceptance Criteria

Acceptance Criteria:
- Are (generally) being written for, and will be confirmed by, the stakeholders in the story
Tasks:
- Are being written for team members (i.e., people with technical expertise)

Properties of Good Stories - INVEST

Independent:
- Dependencies can't be eliminated (and related stories are sometimes called themes) but should be minimized so that stories can be prioritized
Negotiable:
- Must understand that stories are not "set in stone"
Valuable:
- From the product owner's (i.e., business) perspective

Properties of Good Stories - INVEST (cont.)

Other Kinds of Information

Nonfunctional Requirements:
- May or may not be written as stories
Knowledge-Acquisition/Analysis:
- Should include a discussion of the business value