What’s the difference between a user story and a use case?

User stories and Use cases have the same intention.
Many years ago I was at a restaurant in Bombay together with two colleagues, Anup and Rama. We were seated outside and waiting for our food. It was windy and on our table was a stack of napkins that almost blew away. Anup flipped the stack hoping that the napkins would not blow away but as the wind kept on blowing the napkins kept on almost blowing away. Over the next couple of minutes Anup would turn the stack of napkins over from one side to the other several times. Finally Rama took a glass and put it on top of the stack and the napkins were secured in place.

Both Anup’s and Rama’s intention was to secure the stack of napkins in place but they approached it in different ways. In just the same way user stories and use cases have the same intention -to help teams build the right thing. But they do so in different ways.

With this article I hope to illuminate some of the differences between a user story as described by Mike Cohn, and a use case as described by Alistair Cockburn. I will however not answer which of the two is better. Trying to answer that is like trying to answer if a fork or a knife is better. They solve different problems and work good or bad depending on how you adopt them and your context.

If you want to know the difference but not want to read the whole article skip ahead to my summary under the section “User stories and Use cases are different tools.”. An even shorter summary is that User stories help you ask questions and Use cases contain the answers to your questions.

Meet John the product owner.
Now let’s look at how John, the product owner for a music streaming service, and his team develops a feature with the help of a user story and then a use case.

John and his team develops the desktop and mobile client for a music streaming service. John does AB-testing and also regularly solicits feedback from his users in user tests. One day at the end of some user test he gets the following feedback:

“I listen to music everyday going to and from work. I do not have an automatic renewal of my subscription because it is important for me to keep a track of my costs. I use prepaid gift certificates instead of credit cards as my method of payment because this gives me total control of my costs. It is not possible to add a prepaid card directly in the app which means that when my subscription expires I must access my account via the website. And I can never remember my password so before I can renew my subscription I need to reset my password. After changing password and renewing my subscription I have to login to the app all over because I have changed password. All of this takes me 5 minutes because my internet connection is also slow. I want to be able to renew my subscription using prepaid cards directly in the app to save time and not change my password.”

John recognizes this feedback. Many customers have complained about this in the past. John has AB-tested displaying the subscriptions expiration date in the mobile app but with a neutral result. So John has now decided to add the possibility of renewing subscriptions using prepaid gift certificates directly in the mobile app.[1]

User stories gets a discussion started, many times the wrong one.
John jots down the user story ”A user can renew her subscription using prepaid gift certificates in the mobile app”.

John reads this story to his team in his next backlog grooming and why this is important. The team asks follow-up questions such as ”what do gift cards look like?”, ”are there different types of gift cards?”, ”is there a database with all the unused gift certificate numbers?” and John fill in the gaps. John and the team agrees that the story is considered done when the users can renew their subscription in the mobile app both before and after the subscription has expired. They also agree that the subscription, if renewed before the expiration, is prolonged from the expiration date. John tells the team how he will test the story once it has been completed. After this discussion the development team starts discussing how to implement this.

The user story serves as the starting point for Johns discussions with the dev team, and it starts the dev teams discussion about how to implement the feature.

Now let’s look at what a use case created based on the same feedback looks like.

Use cases contain your decisions.
John sets up a meeting and makes sure that his stakeholders from legal and finance are present. He also makes sure that at least one programmer and one UX from the dev team is there. Before the meeting John creates a “casual use case” also called a “narrative” and he shares it as the meeting starts.

”Everyday as Lisa goes to and from work she listens to music with her iPhone. One day the music stops playing and Lisa discovers that her subscription has expired. Lisa never remembers when her subscription expires and she forgets her password easily. This is not a problem for Lisa because she can renew her subscription directly in the mobile app. Lisa opens the app and renews her subscription by entering the code available on the back of the gift certificate. Lisa is very happy because she can renew her subscription directly in the app and it takes her less than 30 seconds.”

Shortly after John has shared this narrative the stakeholders start discussing the narrative. They identify where gift certificates are stored and the data that finance needs for reporting purposes. They also discuss ”What happens if the gift certificate has already been used?”, ”What if it has expired?” and many other questions and “what if’s”. One of the main purposes with this meeting is to identify what should happen, and all the ways this can go wrong and what happens if something goes wrong.

After two hours they have made many decisions that have been documented as a use case. Their use case[2] is now:

1. Narrative: “Everyday as Lisa goes to and from work she listens to music with her iPhone. One day the music stops playing and Lisa discovers that her subscription has expired. Lisa never remembers when her subscription expires and she forgets her password easily. This is not a problem for Lisa because she can renew her subscription directly in the mobile app. Lisa opens the app, presses “settings” and then presses “payments”. Lisa then presses “renew subscription” and enters the code available on the back of the gift certificate. Lisa is very happy because she can renew her subscription directly in the app and it takes her less than 30 seconds.”
2. Actor: End-users
3. The goal of the actor: To renew a monthly subscription using gift certificates directly in the app without needing to enter user credentials.
4. Preconditions: The gift certificate database needs to be online. The app needs to be in online mode. The user needs an unused gift certificate. And the subscription needs to have expired.
5. The main success scenario: (i.e. if everything goes according to plan, what should happen?) e.g.
   1. Step 1: Subscription expires, app stops playing music and then informs the user with a prompt saying so.
   2. Step 2: User presses settings and accesses renew subscription.
   3. Step 3: User enters the gift certificate number and presses “renew”.
   4. Step 4: The app validates the certificate number.
   5. Step 5: The gift certificate is approved, the subscription renewed, and the app informs the user with a prompt saying so.
   6. Step 6: The user presses play and the music is resumed.
6. Extensions: (The failure scenario. – i.e. What are all the ways this can fail, and what should happen in that case.)
   1. Extension 1 – Incorrect gift certificate number.
      1. Step 1: The app validates the certificate number.
      2. Step 2: The certificate number is incorrect and the user is prompted with a message saying that the number is incorrect.
      3. Step 3: The app asks the user to enter a valid number. The last number is removed and the user has to rewrite the whole number.
      4. Step 4: The user enters a correct number.
      5. Step 5: The user is able to renew his subscription and steps 5 and 6 from the successful scenario play out.
   2. Extension 2 – Expired gift certificate.
      1. Step 1: The app validates the certificate number.
      2. Step 2: The certificate number is incorrect and the user is prompted with a message saying that the number has expired.
      3. Step 3: The app opens a prompt asking the user to contact fraud@app.com if the user knows that this is an unused number.
      4. Step 4: The user presses close on the message and the user sees the “renew subscription” page and can enter a new gift certificate number.
      5. Step 5: The user enters an unexpired/other number.
      6. Step 6: The user is able to renew his subscription and steps 5 and 6 from the successful scenario play out.
   3. And so on with every extension that the analysis team identifies.

The analysis of the narrative has been completed and John shares it with the rest of the dev team.

The dev team is happy because the decisions about how the feature should work have been made with all necessary stakeholders. This means that they are less likely to discover missing information once implementation has started so development will not stall.

Use cases should in just the same way that user stories should be discussed with and within the team. Use cases are not intended as an instruction that the team gets sent via email with no dialogue with the product owner.

User stories and Use cases are different tools.
User stories do not give a complete picture and are not meant to. User stories are meant to initiate a discussion with the development team.

One downside with user stories is that they focus on what should happen i.e. the success scenario leaving out the “what if” parts i.e. the extensions. John could write extensions as user stories but one of the strengths with use cases is that they provide a template for identifying and communicating extensions.

Another challenge with user stories, in my experience from working with development teams, is that when teams discuss user stories the developers write down the information that they get from the discussion in their own notepads. After this discussion the user story phrase only acts as a reminder of the discussion that was held. However John’s use case contain the decisions that he, the team, and stakeholders has made together. The use case is the go-to place to understand what to develop.

Compared to User stories Use cases require more work upfront. And while writing a narrative might take 10 minutes it provides more context than a user story.  Writing a full use case can take anywhere from 10 minutes to hours, or possibly even days. It is sometimes worth spending days creating a use case. Consider the importance of investigating extensions for health products such as pacemakers, banks, and other applications with extensive security requirements.

This is why we[3] say that ”user stories are a discussion waiting to happen” and that the “use cases are the documentation of decisions you have made”. Use cases can also be described as “a ‘contract’ for the behavior of the system being discussed”. User stories create questions and Use cases answers them.

So which is better – User stories or Use cases?
In the beginning of this article I mentioned that i do not have the answer to the question which is better. Neither User stories or Use cases in themselves are bad tools. But how you choose to adopt them and your context is what determines your success.

Use cases can likely help you if you work in a dev team that never does any analysis upfront. The same goes if you regularly have to stop development because you need answers from stakeholders, or if you don’t even know who your stakeholders are. If you on the other hand do lots of up front analysis and never get to the actual development, you should try spending less time on analysis.

I like using both. In teams with stakeholders that are present during planning meetings and during the sprint, user stories work fine. This is because the team can get the answers they need with short lead time. But in teams with many stakeholders or with stakeholders that are often unavailable, use cases help by making sure that decisions are made before the team starts, thus limiting the need for sync during a sprint.

Throughout my career I have encountered teams, product owners and others who use user stories and use cases interchangeably, but they are as different as a fork and a knife. A fork and knife goes well together but you don’t always need both, and they solve different problems.

if you think that user stories and use cases are the same, you at best miss out on an awesome tool. At worst, you risk causing confusion and missing out on two tools. You also risk creating the wrong product, or spending a longer time than necessary developing your product or in planning.

I hope this article has helped clarify the difference between these two tools so that you can get the most out of them.

Thanks for reading!

Footnotes:

 [1] – The more common way of writing a user stories would be: “As a user I can renew my subscription using prepaid gift certificates in the mobile app because I forget my password and I want to avoid resetting my password every month.”. Both are valid story formats and I think it is time we stopped following the <as a, i can, so that> format slavishly.

[2] – There are many ways to create a use case and levels of details to it. This is John and his team’s use case. This article does not intend to describe everything a use case can contain.

[3] – We = Coaches, authors, product owners and others within the agile community.