What are user stories, and why should I use them?

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.


About the Author

Jonathan Babcock is a management and IT consultant with expertise in business analysis, process optimization and solution delivery methodology. Practical Analyst is his outlet for sharing what he's learned, and for interacting with solution delivery professionals across the globe.

Author Archive Page


  1. Except for the “torn up and thrown away” part, it seems to me that “scenario” (in use case terminology) and “user story” are pretty much identical.

    As for the “torn up and thrown away” part–well, I have yet to find a place where this actually was OK in real life. Almost every Agile project I’ve encountered ended up requiring a major documentation effort after the project wound down and the business owners started to realize that the only people who knew how the system worked were leaving.

  2. I appreciate the comment, Kevin – and I love the new IIBA blog. You guys are doing a great job.

    I also got the impression that there isn’t a great deal of difference – semantics aside – between the user story and the use case scenario.

    I’m admittedly more a student of agile methods than a practitioner. I’ve read the books,the articles and the blogs and have participated in a few quick projects that were termed “XP” or “rapid development”, but have never worked extensively in what purists would consider an agile environment. I do have to agree that, regardless of the methodology, tossing documentation that represents important decisions and rules seems like risky business.

Post a Reply to JB Cancel Comment

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