Skip to content

User Story Intro

Agile Development

User Stories

Qualities of a Good User Story

  1. Independent
    • If they are independent, we can work on them without concern for story order.
    • Not always possible
  2. Negotiable
    • A good story must be able to change or adapt
    • Used as an initial summary that can trigger new discussion, and should capture new information.
  3. Valuable
    • User should perceive the user story as something important to the application.
    • Helps establish story priority
  4. Estimable
    • Must be able to estimate Time or Effort
    • Depends on collaboration, skill and knowledge on the team
    • Priority should be based on Value and Effort
    • Effort estimation should be based on past user stories
      • e.g. If it took 2 weeks and 3 developers to create Login Feature
      • Role Based Security, which is more difficult, can be estimated at 4 weeks
        • Anything longer than 2 weeks should be split into smaller stories
  5. Small
    • Must fit in a 2 week sprint
    • Easier to estimate time/effort
    • Reduces risk
    • Psychological impact of finishing something
  6. Testable
    • Makes sure product matches promised deliverable.
    • Adds 2 parts to User Story Template (Acceptance Criteria, Definition of Done)

Template:

  1. As a (who wants to accomplish something)
  2. I want to (what they want to accomplish)
  3. So that (why they want to accomplish that thing)
  4. Acceptance Criteria - Metric of Story Progress
    • List of requirements at user or system level
    • May also include system flow diagrams or sequence diagrams here.
    • Must be specific to the User Story
    • Must be met to ensure store is complete.
  5. Definition of Done - Metric of Sprint Progress
    • List of criteria for ALL User Stories
    • Sprint work only complete once all criteria are met

Example:

  1. As a bank customer
  2. I want to withdraw money from an ATM
  3. So that I’m not constrained by opening hours or lines at the teller’s
  4. Acceptance Criteria
    • Pre-Condition: the user is a bank customer
    • Pre-Condition: the user has an active ATM card and PIN
    • The user can access the ATM with their ATM card and PIN
    • If the user enters the wrong PIN.
    • Then the user’s card is rejected and returned.
    • The user can enter how much money to withdraw
    • The user takes cash and gets their card back
  5. Definition of Done
    • ATM code is documented in UML diagrams
    • ATM withdraw feature passes regression testing
    • Help documentation is written