- Forward


User Stories
An Introduction


Prof. David Bernstein
James Madison University

Computer Science Department
bernstdh@jmu.edu

Print

Overview
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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: Click here for a demonstration.
    • 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
Back SMYC Forward
  • Purpose:
    • Expose the details of a requirement
  • Participants:
    • Development team
    • Product owner (from Scrum)
    • Stakeholders
  • Purported Benefits:
    • Conversations are a richer form of exchange
  • Documentation:
    • Conversations may be supplemented with documents
Confirmation
Back SMYC Forward
  • 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
Back SMYC Forward
  • Epics:
    • Might span one or more releases (over many months)
  • (Sprintable/Implementable) Stories:
    • Small enough to fit into a sprint
From Stories to Tasks
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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.)
Back SMYC Forward
  • Estimatable:
    • By the team (that will design, build and test them)
  • Sized Appropriately:
    • For when they will be worked on
  • Testable:
    • Verifiable
Other Kinds of Information
Back SMYC Forward
  • Nonfunctional Requirements:
    • May or may not be written as stories
  • Knowledge-Acquisition/Analysis:
    • Should include a discussion of the business value
There's Always More to Learn
Back -