Get certified - Transform your world of work today


User Stories Versus Use Cases

What's the difference, and which one do I use in Scrum?

16 October 2015

Mat Chacon

The difference between user stories and use cases can be challenging to understand and explain, especially if your team is making a transition from a Waterfall software development environment to Agile and Scrum. Having experienced this challenge myself in the past, I thought it would be helpful to provide simple definitions of each, then finish with why a user story is better than a use case in Scrum.

What is a user story?

A user story is a simplified description of a requirement or feature written in the form of:
As a <who>, I want <what> so that <why>.

Using this format to write user stories provides your customers with specific features that give them real value. User stories are typically written on a card that provides a brief feature description, elicits a conversation among the delivery team that helps them understand the details, and confirms those details in the form of acceptance criteria, which can be turned into test cases to validate completion of the story. These are known as the 3Cs -- card, conversation, and confirmation.

What is a use case?

Use cases focus on how your system interacts with other systems and actors and are typically extremely detailed, much more so than a user story. Traditionally, these are written by a single person or a small group of people and require someone else to sign off on them, which can take many days to accomplish. This is completely counter to Agile and not part of the Scrum framework. User stories enable your Scrum teams to be more effective by avoiding outdated and time-consuming approaches to software development such as use cases.

If you have recently transitioned to an Agile method and Scrum framework, and someone in your organization wants to write detailed use cases before a sprint planning meeting or ahead of developing the product backlog, and then requires that you or your product owners sign off on those use cases, you should most definitely push back.

Why a user story is better than a use case

Start by asking, "Why are we writing use cases as part of the user story?"

The answer is usually, "To remove ambiguity in what we are delivering." Well, that's the job of the product owner and the delivery team. During sprint planning, the product owner presents the delivery team with user stories that describe what the customer wants delivered and answers questions of why the customer wants those things delivered.

The delivery team figures out how to deliver what the customer expects.

That work will be in the form of tasks that include writing code, writing tests, executing tests, fixing defects, and more. The delivery team removes ambiguity by asking questions of the product owner during sprint planning as they review the user stories, which are meant to elicit conversations.

In Scrum, it is not the job of only one person to write a use case.

This only serves to remove the delivery team from the actual planning stage and puts the product owner in a "sign-off" role she or he was never meant to be in.

A user story contains enough detail to remove ambiguity.

As you work through this process, you will more than likely discover that use cases are no longer required on your projects and that each user story contains enough detail and acceptance criteria to remove all ambiguity. This detail should not be developed before a sprint planning session because the delivery team will be unable to provide input into what and how something will be delivered.

A user story increases the team's understanding of what's required.

Make writing a use case a task in the sprint planning session for each user story if the delivery team determines that it still needs use cases. This exercise will actually help the team understand that use cases are no longer required and that each user story is much more efficient at helping the team understand exactly what is required.

User stories are more efficient than use cases in Agile and Scrum, as they help remove ambiguity in what your team is delivering by eliciting conversation and collaboration within the delivery team. As each user story helps ease the transition to Agile, you will quickly find that use cases tend go the way of the horse and buggy within about three sprints.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.9 (32 ratings)


Tony Bresse, CSM, 12/7/2016 6:28:04 PM
User Stories & Use Cases can definitely compliment each other, and here is how:

A User Story defines the requirement.
A User Story helps defines the Use Cases.
A User Story helps defines alternate flows of Use Cases.

A Use Case defines the interactions needed between the user and the system to meet the solution of the User Story, including detailing the exceptions handling, the business rules, the data mapping, the User interface design.

A User Story can be described enough without details defined in a Use Case.

My advice is to keep it simple, Start with User Stories and Document Use Cases as needed by your team.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up