I have used user stories – or at least something similar – to help me identify user requirements, but have never used them as the means of documenting requirements. I am somewhat familiar with the concept, though, and have been interested in learning more.

I found a great deal of help in Mike Cohn’s article, Advantages of User Stories for Requirements. In this article, Cohn explains user stories and the advantages of using them over traditional, natural language requirements and use cases.

Below is a brief synopsis, but you’ll really want to read the full article. Mike has gone to a fair amount of detail providing useful, practical examples for comparitive purposes.

On the composition of user stories:

Each user story is composed of three aspects:

  1. Written description of the story, used for planning and as a reminder
  2. Conversations about the story that serve to flesh out the details of the story
  3. Tests that convey and document details that can be used to determine when a story is complete

On the weaknesses of natural-language requirements specifications:

  • IEEE 830-style requirements (“The system shall…”) are “tedious, error-prone, and very time-consuming.”
  • Traditional requirements are boring to read, which means that for longer documents, readers are inclined to skim through the document and skip sections.
  • Traditional requirements focus on a “checklist of requirements rather than the user’s goals.”
  • It is difficult to prioritize individual requirements listed in a specification of hundreds of requirements.
  • It isn’t practical to provide budget and time estimates for individual requirements, but it is for user stories.
  • User stories are more reader-friendly and easier to prioritize.

Comparing user stories to use cases:

  • Use cases typically convey larger scope than user stories. User stories are purposely capped to fit within a targeted delivery time frame.
  • A user story basically corresponds to the main success scenario of the use case.
  • Use cases often become permanent system documents; user stories “are not intended to outlive the iteration in which they’re added to the software.”
  • Use cases often include interface and implementation detail. User stories do not.

Cohn is pretty convincing, and, having read his article I definitely understand some of the merits of user stories. However, I am left with a few questions to research. For example, I understand that user stories are not intended to serve as system documentation. Often they’re torn up and tossed after the iteration in which they’re implemented.

I think there is great value in having a documented repository of system requirements or use cases, though – basically a snapshot of what our system does today. I wonder how that is addressed in an environment that uses user stories for requirements?

In any case, Cohn provides a great starting point for understanding user stories, and I’m certainly interested in learning more.

Have any comments or successes to share on user stories? I’ll be interested to hear them.