Any good Agile team knows the difference between Use Cases and User Stories. They deploy both to outline requirements. But the purposes of User Stories and Use Cases could not be more different. Let’s define our terms.
User Stories are simple short descriptions of a feature or bug fix written from the end users’ perspective. User Stories should explain what the team needs to accomplish in common, non-technical language. User Stories, by their nature, should not delve deeply into technical details. The team instead wants to write a simple declarative statement to explain what the user wants and what result they want to achieve. User Stories can look something like this:
“Bill, a florist, wants to track which flowers customers buy most often. He needs a database to keep track of all the flowers he sells.”
“Sandra, a car owner, would like to keep track of how much her daily commute costs her. She needs a way to track all her car-related expenses.”
User Stories follow a simple structure. The goal is to summarize the User Story in a sentence or two. User Stories usually follow this structure:
As a
I want to
So I can
As you can see, User Stories give a high-level overview of a feature or bug fix. Teams aim to tackle one user story per sprint.
Related post: Converting Story Points to Hours: Why Doesn’t It Work?
Use Cases describe the relationships between a system and users or actors. Use Cases lay out in detail what Users Stories describe at a high-level. Writing out Use Cases helps teams to understand the implications of User Stories. User Stories start the process, Use Cases dive into the details. Good Use Cases contain most of the following information:
Goal
User / Actor
Preconditions
The standard path to success
Possible alternate paths or variations
Post conditions, end state
Use Cases give the development team a space to describe how a system will function in detail. While User Stories aim to describe a Sprint in layman's terms, Use Cases use technical language and great detail.
What comes first, use case or user story?
User Stories start the software development process. In Sprint planning meetings, Product Owners share the User Stories at the top of the backlog. The software development team asks questions and seeks clarity on the User Stories. They seek to understand requirements and the definition of done. By the end of the Sprint planning session, the team should have a clear idea of how the Sprint will proceed.
Daily Standup meetings help the team stay the course. In each short meeting, the team communicates with the Product Owner any roadblocks or issues they face. They ask questions and share their progress. They share what they have completed the day before and what they would like to complete in the coming day. Daily Standup keeps the team focused on the User Story.
So as you can see, User Stories and Use Cases serve different purposes. They both describe goals for the user. But you cannot substitute one for the other. Product Owners should create User Stories first. User Stories should describe a feature in general, everyday language. User Stories describe the benefit of a feature or function. Use Cases describe, in detail, how the team will create that function, how they will meet that goal.
What are the key similarities and differences between a user story and a use case?
User Stories focus on who, what, and why. Use Cases describe how we will build the process to achieve the goal of the user story. User Stories apply to a single Sprint, whereas Use Cases may cover more than one Sprint.
Software development teams write User Stories as a very brief and succinct description of a small feature or fix. On the other hand, Use Cases offer a detailed overview of a system or set of functions. The structure of the two also proves very different. User Stories should be just a sentence or two. We could write out a User Story on an index card or on a post-it note. A User Story should not take a lot of time to write.User Cases take more time to create. Use Cases should spell out in detail each step the team needs to take to complete the Sprint. Many teams find it best to write out the Use Cases in the form of a diagram. A diagram helps teams to identify places where the process flows less than smoothly.
User Stories
Use Cases
Written in plain language
Detailed Technical Language
General
Specific
Usually a sentence or two
Longer description or detailed diagram
Written from the end-user’s perspective
Written in technical language for the development team
Describe a feature or function
Describe how to create that feature or function
Fits a single Sprint
Can take up multiple Sprints
Easy and quick to write
Should take time and effort to create
So which should you choose for your project, User Stories or Use Cases?
It really depends on the scope of the work. If the project is not too complex, User Stories might prove sufficient. If the project is complex with dependencies, Use Cases may make more sense.
Many teams find the best way to work is to use both User Stories and Use Cases. Using both allows teams to have the best of both worlds. They first describe their Sprint in simple terms that all team members and stakeholders understand. Then the team builds the Use Cases, fleshing out the User Stories. This gives them both simplicity and detail, structure and creativity. Teams that use both User Stories and Use Cases have better focus and clear expectations for their project.
Here at Blocshop, we are big fans of User Stories and Use Cases. Using Agile and Scrum our teams work hard to deliver results, on time. If you’d like to learn more about how we harness the power of Agile, please get in touch!
