User stories vs use cases in agile development

Sometimes people bring up the question of whether to work with user stories or to work with use cases in agile development. My brief and opinionated answer to this is:

• User stories and use cases are methods for working with product requirements
• User stories came to replace its precursor use cases, and for good reason
• The main problem was that use cases led to a lot of upfront work
• User stories allow for thinking high-level first, and then figuring out the details
• However, when figuring out the details, use case-thinking can be valuable

Next I will briefly go through the two methods, the case for user stories, and how to benefit from use case-thinking.

User stories vs use cases: A tale of two methods

Use cases

Use cases is a method for capturing, modelling and specifying product requirements. It was first presented by Swedish computer scientist Ivar Jacobson in 1987. This is 14 years before the Agile Manifesto was published. By the standards of the world of computer science, use cases is an ancient method.

‍

The idea is that a product can be described using many use cases, each following the below formula:

Use Case Title - Commonly an action verb and a noun

Primary Actor - The user who interacts with the system

Precondition - The state in which the scenario occurs

Guarantee - The end state after the scenario has run

Main Scenario - Description of the steps in the main scenario

Alternative Scenarios - Description of the steps in relevant alternative scenarios

‍

An example use case could look like this:

Use Case Title - Sign up with Google account

Primary Actor - New user

Precondition - New user has pre-existing Google account & is on main website

Guarantee - Signed up with account linked to Google account

Main Scenario

1. User clicks link to sign up with Google account
2. System sends user to Google login screen
3. User enters Google account credentials
4. System gets user verification from Google with unused email
5. System creates a new user based on a Google account
6. User proceeds to welcome screen

Alternative Scenarios (Pre-existing password-based account)

1. User clicks link to sign up with Google account
2. System sends user to Google login screen
3. User enters Google account credentials
4. System gets user verification from Google but with email already in use by another password-based account
5. ...

User stories

User stories is a method that is in many ways similar to use cases. It was developed roughly by the same people and at the same time as the Agile Manifesto. In 1998 Alistair Cockburn stated that "A user story is a promise for a conversation", and in 2001 Ron Jeffries came up with the "Three Cs" for working with user stories.

The idea is that increments to a product can be described as user stories, specifically split into:

Card. This comes from the fact that in the beginning the user stories were written on index cards. It is a short hand description, often expressed by something like: "As a [role], I can [capability], so that [benefit]". Comparing to the use case, this format corresponds to something like a combination of the Use Case Title and the Primary Actor, with an additional point on why the story is relevant.

Conversation. This represents everything that is said about the story as it is being refined. Ideally everyone will be in the same room, but since that is rarely the case, it often means this will have to be written down.  Comparing to the use case, this is where the scenarios would be captured, but also other decisions and details - in text, as designs, through data.

Confirmation. This is the end point of refinement, a commonly agreed expression of what it will mean for this user story to be fulfilled. It often comes in the form of acceptance criteria or as reference designs. Comparing to the use case, this most closely corresponds to the Guarantee, but other factors could also be added, such as performance, design fidelity, and more.

Using the same example as before, but as a user story, it could look something like this:

‍Card. As a new user, I want to sign up using my Google account, so that I don't get another password to keep track of.

Conversation. (Not necessarily as neatly organized as Card / Confirmation, but probably containing the scenario steps from above with questions e.g. on how to handle existing password-based account; some technical notes, e.g. OAuth; maybe some quote from a customer; maybe some designs for how it will look).

Confirmation. Acceptance criteria:

• Signed up with account linked to Google account
• Don't need to come up with a new password

How user stories came to replace use cases

One of the values of the Agile Manifesto is "Working software over comprehensive documentation". A common misconception is that this means "no documentation". It does not, in fact it is crucial for PMs to master working with product requirements documents (PRDs). However, it means that heavy upfront investment in documentation should avoided, as an early large build-up of documentation reduces the ability to course correct. In other words, it makes the process less "agile".

The main problem with use cases was exactly this, that they often led to a lot of upfront work, where business analysts would try to think through all the scenarios and all the steps of all the use cases before talking with the developers and getting started. It is easy to imagine that this led to massive amounts of documentation. Then all this documentation would fall down on the developers, in something similar to a "waterfall".

This is the historical context in which user stories should be understood. The idea user stories come with is that the only thing that is needed at first, is a simple index card with a brief story from the user's perspective. By delaying the adding of more details, it is possible, very early on, to have an insightful discussion ranging across user stories about what to develop in the near-term, for example using a user story map. Then, during the refinement of what it would mean to develop a user story, done together with the developers, as much detail as is necessary should be added. This workflow is more effective, but it also requires more of the PM in terms having a full range of product management skills.

How to benefit from use case-thinking

Two common problems when working with user stories

First, not capturing the conversation or expressing the confirmation properly. The user story method gives a lot of freedom to product managers when when it comes to what to capture, write down, and share, especially compared to a more rigorous method like use cases. But just as the use cases method nudges PMs to do unnecessary upfront documentation, the user stories method nudges some PMs to hardly capture any details at all. This is a big mistake, especially if it means not capturing the conclusion of the conversation - a set of agreed acceptance criteria for when a user story is fulfilled.

Second, not thinking through the main scenario and the alternative scenarios properly. The use cases method pushes PMs towards write out all scenarios and steps early on, but the user stories method gives PMs a lot of freedom and so the risk is that they don't think about scenarios and steps at all. Not thinking through the steps the users will go through before actually starting to build new features is almost always a mistake. In the example from before, it might have meant not thinking about the scenario where the user already had a pre-existing password-based account. The idea is to not be forced to do it early, not to not do it at all.

Have a use case-mindset

To get around these two problems, it can often be helpful to have a use case-mindset when working with the developers on refining features to be built in an upcoming sprint.

For each user story, this means stopping to think, putting on the use case hat, and asking questions like

• What are the steps to go through the user story?
• Are there any alternative scenarios to consider?

Sometimes there are very few steps and no relevant alternative scenarios. In those cases, adding information on scenarios and steps to the notes from the conversation might be overkill. Often there are lo-fi sketches made that show the steps of both the main scenario and some alternative scenario. If that is the case, then those sketches can do the job of documenting the scenarios and informing the formulation of the acceptance criteria. But if you have a feeling that there might be some non-obvious scenarios or steps lurking under the surface, then it is most definitely a good idea to start thinking about and writing down different scenarios and steps.

Flexibly adding details to user stories with an outliner

When trying to reap the benefits of both user stories and use cases, it can be very helpful to work with an outliner. An outliner is a type of tool where the whole document is structured like a tree, and the user can add details.

To get the benefit that user stories have of being able to quickly write them down on short-form, and then sort and iterate on them - outliners have functionality that allows for collapsing all the details within and just looking across. This can for example be used to conduct user story mapping.

To get the benefit that use cases have of being able to deep dive and write and work with detailed scenarios and steps for each, not to miss any relevant detail or edge case - outliners have functionality that allows for expanding to show content below, or even zooming in and only showing one or a set of scenarios with their steps.

To be able to get the best of both worlds, it is possible to quickly and seamlessly go between these view modes. To be both on the balcony, and in the dance, as it were.

In the next step, when you have detailed each user story (with e.g. scenarios with steps, images, Figma designs), if you are using Delibr as your outliner, you will also be able to link up each user story directly to an issue in Jira, and have all the details show up there, with real-time two-way sync.

Get started with a good template, either an epic template, or a user story template (and if you are unsure, you can read up on the difference between epics and users stories). If you have not tried the combination of working with templates in an outliner, you are in for a treat.