User Story Examples and Counterexamples

People who share my background in traditional requirements analysis often have a hard time coming up with Product Backlog Items representing thin vertical slices of potentially-shippable product. Here are some good and bad examples that people have found useful.

GUIDELINES

User Stories may assume template form (see User Stories Applied by Mike Cohn):

  • “As a [role] I can [function] so that [rationale].”

 

or expressed as noun phrase:

  • “Image clipboard”

 

or a 1-2 sentence story (ideally a testable assertion):

  • “Busy streets are highlighted on the map.”

 

User stories, like all Product Backlog Items, should contain or clearly imply acceptance criteria (definition of “done”). Write these on the back of the index card, or in the “Description” field if you’re using an electronic tool.

Bill Wake has given us the INVEST mnemonic to help remember the characteristics of a well-formed user story:

  • I – Independent
  • N – Negotiable
  • V – Valuable
  • E – Estimable
  • S – Small
  • T – Testable

EXAMPLES

What does this look like in practice?

  1. A bank customer can change his PIN.
    • Acceptance Criteria: ….
  2. As a student, I can find my grades online so that I don’t have to wait until the next day to know whether I passed.
    • Acceptance Criteria: ….
  3. One level of undo
    • Acceptance Criteria: ….
  4. As a book shopper, I can read reviews of a selected book to help me decide whether to buy it.
    • Acceptance Criteria: ….
  5. As an author, I want the spell checker to ignore words with numbers so that only truly misspelled words are indicated.
    • Acceptance Criteria: ….

COUNTEREXAMPLES

How do we know when we’re missing the mark? Ultimately “User stories are a promise for a conversation” (Ron Jeffries). If Product Owner and Team both know what they mean, you’re off to a good start. But you can probably save some time by avoiding the common pitfalls below:

  1. “Design brochure layout.”
    • Drawbacks: not Independent, no business Value. This is a task representing a horizontal architectural layer or phase. The architecture will be done in a vacuum, possibly contributing to analysis paralysis.
    • Better: “As a dog owner, I can find a meal schedule on the brochure so I know whether this doggy day care center is appropriate for my hungry dog.”
      • This will lead to only the necessary amount of design to support this Sprint’s features. The layout might change the next Sprint, but rework is cheaper than no work.
  2. “Write game rules.”
    • Drawbacks: not Independent, no business Value, not Small.
    • Better: “As a newbie game player, I want to know who goes first so we can start the game.”
    • Better: “As a competitive gamer, I want a way to leapfrog my opposing players.”
  3. “I want the brochure to be colorful.”
    • Drawbacks: not Independent, not Estimable (without knowing other features of brochure), not Small.
      • This is an easy trap for those of us who grew up with the habit of writing “the JFIDM _shall_ comply with the IEEE-488 interface specification.”
    • Better: Use “colorful” and other cross-cutting requirements as acceptance criteria on each of the specific features in the backlog they apply to.
  4. “As Product Owner, I want a list of highly-rated restaurants on the brochure.”
    • Drawbacks: It’s not only about you!
    • Better: Focus on your end users and stakeholders. “As a gourmet tourist, I want a list of highly-rated restaurants on the brochure.”
    • Better: “As the Chicago Public Health Department, I want warnings about restaurants that serve raw ingredients so that tourists don’t get sick on our dime.”
  5. “Play test the game.”
    • Drawbacks: Not Independent. Encourages phasewise development.
    • Better: Make testing, refactoring, etc. a default acceptance criteria on every Product Backlog Item.
      • But: If you failed to fully test and refactor in previous Sprints, you are in technical debt! You are already working on a legacy product. In this case you may need to make testing and refactoring first-class Product Backlog Items to make up for your sins. This practice is controversial, and technical debt repayment cannot honestly be called a User Story. A PBI that’s not a User Story may still be useful as a starting point for a conversation about how to reduce technical debt incrementally while continuing to deliver new value.

 
User stories are simple thing. “Simple” is often not the same as “easy.” Happy unlearning!

–mj
Michael James
Software Process Mentor
 
Watch example User Stories being extracted from epics (and estimated in story points) in a Backlog Grooming Meeting.
Backlog Grooming Meeting User Story Examples and Counterexamples
 
For a general Scrum reference, see the 6-page Scrum Reference Card.
To learn more about the Scrum Master’s role, see The Scrum Master’s Checklist and the Introduction To Scrum video.

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
One comment on “User Story Examples and Counterexamples
  1. Tommy Norman says:

    I was often told by one my first PM/BAs that all requirements should be CAMTU:

    Clear, Accurate, Measurable, Trackable, and Unique

    We have been struggling with the granularity of our Product Backlog items for months. Our first effort was too small and our current one is too high level. Your examples and the ones from Mountain Goat are more of what I am looking for.

    Thanks for the post.

    Tommy

2 Pings/Trackbacks for "User Story Examples and Counterexamples"
  1. [...] is a good summation article about user stories Good examples and instructions for writing great user stories You can buy a whole book about writing great user stories Wikipedia of course has an overview page [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

*

CAPTCHA Image

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

connect with CollabNet
   Contact Us
sign up for emails
conversations

CollabNet: Learn to rewire enterprises to become #lean through customer engagement via @thoughtworks http//t.co/4uHlKBtJpg:
Date: 21 August 2014 | 4:00 pm

CollabNet: Be sure to register for our #Agile & #Scrum Essentials class in Texas on August 25-26 with #CalebBrown! http://t.co/FzqjzfREPB
Date: 20 August 2014 | 10:59 pm

CollabNet: Be sure to register for our Certified #ScrumMaster class with #GregorySmith, on August 25-26 in South San Francisco! http://t.co/oaYDsKu6KE
Date: 20 August 2014 | 9:00 pm