User stories vs use cases: how they stack up

Just what exactly are the differences between user stories and use cases? Aren’t they the same? Don’t they have the same goals? Why not just settle on one word for both of them? As it turns out, user stories and use cases, while they do have similar purposes, are not quite the same.

In this post, we’ll have a look at the different formats these documents take and the type of content they contain. Hopefully, after reading this post, the differences will be clearer. You should also have a better idea of which one you should be including in your development cycle.

The agile world is dotted with a seemingly endless population of user-centric documents to use alongside your wireframe tool. The problem is, all of them are helpful.

However, the paradox is that agile is all about cutting through red tape and minimizing surplus documentation. And since many documents have similar functions, to remain truly agile, you may need to decide which documentation is relevant for your team and clients at any given moment. Too many documents and procedures in a small organization might be overkill.

Indeed, many agile documents have striking similarities and some may just be synonymous with others, such as user journeys, user journey boards and user journey maps which are essentially the same thing. Nonetheless, there are some documents that tend to get misinterpreted as synonymous when they are in fact different.

This is particularly true when we look at user stories vs use cases. People sometimes mix up these documents because they sound similar and have familiar goals. However, if you were to see both a user story and a use case side-by-side, you’d quickly notice the differences. Let’s look at what each document entails. If you already have a good idea of what each one is, feel free to skip down to user stories vs use cases for a battle finale!

User stories define the who, the what and the why of a product feature. They’re usually aimed at developers but are intended to be easily understood by everyone on the team, including clients. They outline what a user needs to get done, from that user’s point of view.

They often comprise just one sentence or a couple of lines written in the following structure:

• As a (user)
• I want to (perform some action)
• So I can (achieve some goal)

An example of this could be:

“As a user, I want to have a barcode ticket for my train pass on my phone so that I don’t need to print it off and carry a paper around with me.”

That is then followed by acceptance criteria which usually contain the information that informs the developer or product manager when the user story can finally reach its conclusion, in other words, when the feature is ready. A product manager will normally hold a discussion with design and development teams to agree on what outcomes of the user story need to be satisfied. An acceptance criteria typically takes on the following format:

• Given (how things happen)
• When (action taken)
• Then (outcome of that very action)

Using that format, an acceptance criteria generally tends to look a little like the following:

“Given there are sufficient funds in the user’s bank account, when they enter their details correctly and select a valid hour, the ticket should appear on the dashboard, then a confirmation email and purchase receipt should be sent to the email address the user registered with.”

User stories are often simply written on index cards, something which owes to the pure simplicity of this important agile document. The acceptance criteria is often written overleaf.

However, this isn’t ’t the only medium that user stories can come in and they are often in fact digitalized and written up into excel or word documents or google docs or even PowerPoint presentation format.

They are often included in kanban or other agile software and assigned scrum points for each one There are actually many templates available to help teams to get started with creating user stories and these templates are also all digital.

User stories may seem like a very simple document at first – and that’s exactly the point. However, the effort that goes into creating these simple one-to-two line sentences is not.

Like with everything in agile, plenty of user research will have gone into coming up with those few lines of a user story. And yes, we’re talking about identifying the user persona, creating it and gathering your product requirements.

The beauty of the user story is that it condenses a lot of crucial information and provides it in plain English or layman’s terms. This way, design and development teams don’t get bogged down in technical jargon and liberated to think more creatively about design solutions.

Before agile entered the tech scene to go on and replace the waterfall method as the most popular software development methodology, use cases were a thing. They were developed towards the end of the 1980s as a ULM (Unified Modelling Language) diagram.

In some respects, use cases are similar to user stories, in that they also use plain language and are focused on achieving a particular goal for the user. They are also useful for both technical and non-technical stakeholders. However, unlike user stories, user flows focus more on the functionalities of a feature or process being developed, that is, how a system plays out. It focuses on the various steps taken, both by the user and the system to achieve a goal.

While use cases are sometimes presented as a list of steps, it’s a lot more common to represent these steps in a diagram, like the one below. Some teams prefer to sketch them out their use case diagrams, whereas others prefer to create them using a tool like Lucidchart.

Use cases usually assume the following structure:

• Actor (the user, a group of users)
• System (the product or product feature the actor interacts with)
• Goal (what the actor is trying to achieve through the system)

The use case takes the form of a diagram with the actor/s (users) to the left of a square and the product system or responsible departments of the company to the right.

Inside the square are oval shapes are the steps involved in a process. In each oval it might be “actor creates account”, “actor selects train schedule”…etc. in that sense, it’s true to say that use cases actually focus more on the functionality.

Various teams often add in additional items such as:

• Overview of the user’s goals (brief note beside the diagram)
• A list of all the stakeholders involved
• Members of the design and development team
• Pre-conditions
• Post conditions

The exact items you add to supplement the use case will depend on your organization and the client’s requirements. Use cases, as with most documents in agile, follow a general pattern, but are not standardized.

However, it can be useful to add in an overview to give some background and context to the diagram. It’s also helpful for the client and for your team to know exactly who’s involved in developing the product feature, especially if it’s a large team. This is because, as at some point, you’ll need to coordinate your efforts with theirs.

Including the pre-condition for the system before the user interacts with the feature is a great way to provide context about what the feature should change. It also sheds more light on what state the system should be in afterwards (post condition).

Some use cases will contain post conditions, that is, the state that the system should be in after the actor has used the feature and achieved their goal (and to tell the tale happily to other users!).

Let’s look at an example of the post condition. In the above case of the actor (user) who wanted to buy a train ticket and have the barcode available on their phone for easy access, you might want the system to remember that particular booking. In this way, if the actor subsequently wants to book a train ticket at the same hour and destination, the system might remember those details to shorten the process and to prevent possible data entry errors.

Another good example of a post condition might be a banking app that lets them repeat the exact same transfer more than once but without having to enter in all the same details again such as bank account numbers, they can instead just tap and send.

Now let’s pit user stories against use cases and see up front, apart from the structural format, how these two agile documents differ.

User stories are normally, and purposely, more vague. The user story provides a simplified, abridged description in layman’s terms of what a feature should help the user do. This leaves it more open to interpretation and encourages more creativity and discussion on the part of the design and development teams.

Use cases cover more ground by showing how the user should interact with the system and how the system should reciprocate. They go into further detail about how the individual steps in a feature’s process.

The difference in detail is a big factor in user stories vs use cases. Perhaps one of the main differences between use cases and user stories is that the former are often completed over multiple sprints or iterations. On the other hand, user stories often contain features or details small enough to be completed over the course of one sprint. A team may even get through multiple user stories in one sprint.

User stories are much briefer, more succinct documents and generally tend to be used for smaller features. They can also be used to break larger features down into small steps or multiple user stories. Conversely, use cases tend to give more of an overview of a larger system functionality.

Use cases generally list out the system functionalities required for each step of a feature’s process. It shows you the input required from the user and the system.

There’s also a whopping big difference in the structure when it comes to user stories vs use cases. The user story is just a line or two of a statement about what exactly the user wants to achieve that can be written on a simple index card.

This makes them quick and easy to generate. On the other hand, use cases can take a bit more time to put together, as they detail out each step and are often represented in a diagram.

Because use cases list out the steps and demonstrate them in diagram form, this means they can be helpful in a practical sense for identifying friction points in the process a user undergoes to achieve a goal. However, this can also be done by using a combination of user stories and user flows, which are basically a map of the different screens a user goes through in a process.

If you’re caught between using user stories or use cases, the only answer is that it depends on your team and how big it is. Furthermore, it depends on the type of product you’re working for, your organization and the client.

The best rule of thumb when deciding between the two is to have a discussion with all stakeholders involved in the product. Hash out the pros and cons of each and make a decision on which could be easier and faster for your team. Remember: to keep things agile, you should always try to avoid adding in too much detail.

Nevertheless, you might reach a conclusion where you and your team decide to combine both user stories and use cases. Combining these two documents can also have its payoffs if done strategically.

Use cases make a great addition when combined with user stories because they still keep the plain language tone but go into extra detail about the system functionalities relevant to satisfy the user’s goal.

In fact, if you’re going to implement use cases in your development cycle, some experts recommend starting with use cases first, then moving on to user stories at later iterations. In this sense, you’d be using use cases to underpin the fundamental features of the product, then using user stories when adding the extra features at a later date.

Afterall, there’s something to be said for using use cases at the start of a large project or software development phase. It affords you a more detailed and structured approach.

In general, user stories are an incredibly powerful, simple and versatile tool in an agile environment. Providing your team has carried out adequate research into your user personas, generating user stories can be much faster than generating use cases.

Notwithstanding, if you happen to work for a large client, company, corporation or government body which requires copious amounts of documentation, you might have to use use cases for every feature. However, depending on the scale of your project and stakeholders, like clients, you may decide that user stories are enough to develop the features of your product.

User stories and use cases share some similar concepts but are fundamentally different documents, each with their own unique benefits. User stories are faster to generate, spark conversation and offer a greater degree of creative flexibility. On the other hand, use cases offer up greater detail and a more structured approach to each step but take longer to generate.

The real answer when it comes to choosing between them is that it doesn’t really matter – it’s about whatever helps your team to be the most agile possible. If use cases help your team, there is no reason that they cannot also be implemented into your agile process and used alongside user stories.