Using User Stories

How to write usable stories

  • Define a small domain-specific set of user roles
    • shopper, vendor
    • author, reader, publisher
  • Use a small set of concrete verbs for user actions
    • sees, selects, enters
    • not "finds", "determines", "decides"... -- these are goals or external actions, not app actions
    • not "uses" -- that's way too vague
  • Give real external user goals
    • save money, be entertained, find friends, pass a class, ...

How to implement user stories

Write acceptance tests first.

Code until the acceptance tests work.

Acceptance tests define "done" not "complete".

Acceptance tests

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. [Agile Alliance glossary]

The client or team defines one or more acceptance tests for each user story.

The story is done / accepted when all the examples work.

Given, When, Then

A standard format for writing acceptance tests.

  • GIVEN: some context
    • shopper is logged in
    • shopper has items in cart, ...
  • WHEN: some user action or external event
    • shopper selects "check out"
    • stock of an item in the cart does to zero
  • THEN: what should happen, what should be true
    • shopper sees checkout page with cart items
    • shopper sees "item no longer available" notification

How to write stories that delight

How to find stories that delight

  • Sources of delight:
    • You get something for free (or very little).
    • You get something sooner than you expected.
    • You get something noone else gave you.
  • How to find delight:
    • Narrow your audience. A spreadsheet for birdwatchers can offer features a regular spreadsheet would never do.
    • Leverage re-use. Recommend restaurants users haven't been to already. Suggest team meeting times with no data entry using everyone's Google calendar.