Thoughts on User Stories vs. Use Cases

I came across an interesting discussion of the value of User Stories versus Use Cases which included interesting comments from a number of readers including Alistair Cockburn, well known for his book on use cases and more recently for his contributions to the Agile Manifesto and his ideas describing software development as a cooperative game.

As a Business Analyst, I have of course pondered the same question, and so I thought I would share some of my thoughts on the subject.

Both Use Cases and User Stories have been around for a while. User Stories originated with the advent of the Extreme Programming (XP) movement in the 1990’s and are a key component of most Agile development methods. Use Cases were invented by Ivar Jacobson when he worked at Ericsson in the late 60’s as a way to specify functional requirements and eventually found a home as a requirements technique in the Rational Unified Process (RUP).

So what's the difference, and is one approach any better than the other?

There are different models of a User Story, but generally they share the following commonalities:

  1. They are a very short, concise statement that can fit on an index card or large sticky note. A common form for user stories is “As (user role) I can (activity) so that (benefit).
  2. They are typically written from the user / product owner / stakeholder’s perspective
  3. They may describe a scenario a user finds themselves in, or a specific need
  4. They are specific enough to be prioritized and estimated
  5. They imply a basic acceptance criteria that can be tested

story

A user story should fit on an index card or large sticky note

User Stories are typically collected by the development team via initial meetings with the software stakeholders and then prioritized, estimated and organized into short iterations or “Sprints”.

Use Cases have a number of variations as well, but as with User Stories, share certain commonalities:

  1. They contain concise but detailed descriptions of actor interactions and system responses in a step-by-step format (actor does this - system does that etc.)
  2. They identify specific pre and post conditions as well as triggers for the use case
  3. They identify expected variations in user / system interactions including error/exception cases
  4. The use cases in a use case model typically have identified functional relationships to each other (extends, uses etc.)
  5. They are specific enough to be prioritized and estimated
  6. They imply a basic acceptance criteria that can be tested

So what obvious differences can we see? Well, firstly a Use Case describes both user and system behaviour in a stepwise manner and attempts to include all possible variations including alternate flows and exceptions.

Stories may describe both system and user behavior (more commonly just the user perspective), but don't do so using structured and ordered steps. They also do not attempt to define all possible variations and error scenarios.

Use cases identify pre and post conditions while stories may or may not. For example a story might say: "A registered user needs to be able to login to view profile data." Although there is no specific pre-conditions section, the story mentions "registered" users which implies a pre-condition.

Finally, use case models normally describe functional relationships between the use cases in the model while stories typically do not.

A use case diagram with relationships

So back to our original question – which approach is best for gathering requirements? Both approaches offer significant benefits. Let’s take a look at some of them.

Use Cases evolved out of a need to express the interaction between a system and a user in a way that is comprehensible to both developers and business users. The benefits of such a process are numerous:

  • Use Cases help business users understand and iterate on how a system will behave prior to code development
  • Use Cases help developers understand how a system should interact with the user and as such outline any key business rules the developer needs to understand
  • Use Cases encourage completeness in up-front thinking, reducing the risk of late stage requirements changes (which was a major area of concern when software projects commonly used a more ‘waterfall’ oriented development process).
  • By creating a Use Case model to describe software, and detailing the relationships between the use cases, the model can be directly used as an input to help architect the solution’s technical design.
  • Use Cases serve as an ongoing record of the system design that are useful to new project team members

User Stories, however, are deliberately simpler than use cases for several reasons:

  • Simple expressions of requirements are easier for all parties involved to understand. While use cases are a much better way to express requirements than a laundry list of functional descriptions and 500 page data dictionaries, they are still not a terribly natural method of requirement expression for a non technical business user or product stakeholder. There is a bit of a learning curve to understand the format and meaning of use cases.
  • Attempting to think of every possible variation / pre-condition / post-condition / trigger and error scenario in advance and then documenting all this information in use cases can be time inefficient and may inadvertently set unnatural boundaries on the solution.
  • With Stories, iteration of the requirements occurs as code is developed and reviewed by stakeholders, saving time spent unnecessarily documenting detailed functional requirements that may still end up changing anyway when prototypes start to appear.

OK, so if they both have their unique benefits, how do you decide which is best for a project?

From my practical experience over the years, I have come to support the Jonah Group notion that it is the selection of an engagement approach, not an artifact format, that is more critical to the success of a project.

The selection of an engagement approach depends on the relative priorities of concern of the delivery, operations, and executive teams, whose needs are often distinct (for more background on these ideas, check out our article Agile Development and the Mona Lisa).

It is the selection of an engagement approach, not an artifact format, that is more critical to the success of a project. [This] depends on the relative priorities of concern of the delivery, operations, and executive teams, whose needs are often distinct.

Following that line of reasoning, my experience is that projects with the following qualities are better suited to a more Agile approach (and consequently User Stories):

  • The project is very time sensitive. Getting up and running quickly is more important than having detailed documentation early on in the development process.
  • A small number of individuals have authority to make decisions about the product’s functionality and a formal sign-off process is not required by the organization
  • Subject matter experts are readily available (preferably as full-time team members) to guide developers in completing their assigned stories by answering questions and iterating on the outputs of completed stories
  • The level of business rule complexity is low to moderate, such that conversations between developers and SMEs are sufficient to identify and code the required business rules

On the other hand, I find a use case driven approach often works better for projects with the following qualities:

  • The project is less time sensitive and detailed documentation is preferred for requirements review and signoff.
  • A large number of individuals need to sign off on the functional requirements
  • The client either prefers a more waterfall-oriented project management approach, or needs to fix the price before the project begins
  • The availability of subject matter experts is limited to a few scheduled meetings, and most developed code is only reviewed as part of a formal quality assurance process.
  • The product behavior involves very complex business rules that cannot be easily understood without some form of documentation. In these circumstances, the Use Case model assists developers in understanding how to correctly code the business rules and serves as a resource for knowledge transfer when bringing on new team members or handing an application over to new owners.

So to recap, rather than arguing for one methodology over another, I think it’s better to remain ‘methodology agnostic’, and choose a development strategy that fits a customer’s specific project’s needs as opposed to a personal philosophy.

Ensure that your approach meets the customer’s goals, and you’re sure to succeed no matter what methodology you choose.

  1. I’ve never really seen this explained more concisely. Well done!

    Jeremy Chan
    Dec 2nd, 2010
  2. Thank for this well writed article. I will visit this blog more! How can i stay updated? (RSS) or something??

    Dec 27th, 2010

Add a comment

Comment feed
The better to greet you with
No one will ever see this
Your pride and joy
The reason this comment form exists

The crew behind ASOT

We're a team of interactive, software, and business intelligence experts skilled in the design, construction, and management of online enterprise systems.

Visit The Jonah Group site

Get in touch with us