User Stories vs Use Cases

If you are on an agile team, do you write user stories, use cases, or both? My take is that until you know how to think in use cases to analyze the functional requirements on-the-fly, you need to write them to be sure you’ve got a clear and complete view of what the software needs to do.

What's more, use cases are an incredibly powerful analytical tool to avoid missing functional or software requirements.

Then, if you are on an agile software development team, you might break apart your use case into multiple user stories to help manage the requirements through the software development process.

This is why we continue to teach use cases as a core, fundamental skill at Bridging the Gap as part of our online courses - because knowing how to write use cases makes you a better business analyst.

What’s your take? Leave a comment below.

DOWNLOAD THE USE CASE TEMPLATE (it's free):

WATCH THESE VIDEOS NEXT:

How to Write a Use Case

Requirements Elicitation - What Questions to Ask:

View the Full-Text Transcript Here:

[rataro]

The main difference between a User Story and a Use Case is what they focus on. User stories are focused on the value that will be delivered to the user, while the Use Cases are precise descriptions of how a process flows and its possible alternative paths, so they are focused on the process.

[adventiar]

I am a software developer not a BA and here is my take based on years of experience and reading many books (yes books) about software engineering. Before the creation of the manifesto for agile software development (which sparked the entire agile movement) there were only Use Cases. (no stories) Companies seeking to make profit out of doing "Agile" software development training began to try and sell "Agile" to businesses the term "Agile" became more of a noun than an adjective.

This lead to increased need to define "Agile" and caused allot of what agile actually means to be lost. The practice of agile software development is centered around the idea that software is ever changing and the development process used to produce it should not be unnecessarily complicated. This means don't create things that have no value just because "well that's the process". Like documents no one uses for an example.

In the end "Agile" was defined by creating a set of rules that supposedly came from the original manifesto and were used to define practices that teams were required to use in order to be considered "Agile". (Agile Scrum & Kanban are but two) The "Agile" movement lead to the understanding that software needed to be released frequently. This means you need to complete work in smaller pieces so that that piece can be released sooner.

For example you may have a Use Case that would take 12 weeks to write all the code to complete. But your team may be using 2 week iterations. This means all work started at the beginning of a 2 week period must be completed in that 2 week period. Doesn't always work out since humans are not perfect but we try. This means we can't say that any one unit of work can take longer than 2 weeks. So what do we do? We need to break the work up into pieces so that we can release it one piece at a time.

But remember that each piece must also add value to the application and be testable. Since all work done in that 2 week period needs to actually add value to the application and NOTHING should be released if it hasn't been tested. This is why stories were invented in the first place. Stories are smaller pieces of use cases.

In our example we need to break our use case down into multiple stores that both add value and can be completed within 2 weeks. This is not difficult normally since a use case is already broken down into flows. We just need to compete at least one flow per story. We add all those stores to an epic so we can track the overall completion of the use case and now we can assign the work to a developer to be completed. That work can be completed, tested and released within our 2 week iteration.


Last point is, agile means just that. If you believe a use case has no value then well don't create them. If you don't feel you have a need to break up any of your use cases and don't like stories don't create stories they still have value as ticketing systems used to manage the work typically need some type of ticket to represent the work to be completed and stories are used for that. But you could write the whole sue case in the story or put a link in the story ticket to the use case. If you don't feel like you need to track the overall completion of a use case by adding its stores to an epic then again don't do it. That is part of what agile software development is.

[GodsChildrenOnEarth]

The title is not correct. Use cases and user stories are Not explained and compared as the title suggests.
I am a Business Analyst and did not gain any knowledge about what a User Story is. And that was my main reason for watching this video.

[bhagyashreejadhav]

I have watched lot of your videos and recently landed with a Business Analyst job offer.
Thanks so much!

[generativebusinessmomma]

I agree that a use case is a small, specific, real-life scenario that includes the audience and speaks to their needs ... so that everyone can understand ... no matter if they're on the product team, QA or the business side customer success/sales/marketing. Use Cases can be powerful for clarity on requirements, scope clarity, development clarity and testing!

[srikanthnadakuduru]

Use Case is simply a business scenario, also called an Epic in the agile language.
Whilst the user story is a break down of the business scenario into multiple cases, in a language understandable by the business user. Often the user story is written as,
As a user I want
So that I can achieve
The user stories are then given to development team to develop the software..

[Juicingwithmaddy]

Love your videos so much and your personality ☺️.

[en_coded]

it would be very helpful if you show a sample document while talking about it.

[khavanu]

User stories is just saying what user want for specific role but Use cases are more of his or her interaction with system for certain functions.

[botrrun]

Can you update this video and provide some examples. That would be very helpful. Are User stories made up ofUse Cases or are Use Cases made up of User stories? In an ideal world would you sue both methods or is it best to just pick one?

[aninehartog]

Thanks for this tutorial. How you do Use Case Diagram and Description for a change to an existing system like making existing fields manadory or removing a option from a drop down list.

[ihcho]

Break a use case apart into user stories? Well, it means a use case has a bigger scope than a user story. I almost think that a user story tends to have more features and multiple use cases can be drawn from a user story, even though sometimes you can have 1:1 relationship between a use case and a user story.

[lblockerwr]

QA HERE. Use cases for me have been more of the Parent, where as a User Story is more of the child. Just a small section of a specific use case.

[ahujaa]

As per what I understand User stories are overall process and Used cases is breaking the user stories into parts with respect to functional

Pls lemme know if I am correct or not

[larryackley]

Laura: Have you considered using IJI's 'use case slicing' approach to map use case functionality to individual user stories?

[mohitverma]

I am not clear with the Use case and User stories... What is the basic difference ? I always stranded in these two terms. Please help me out with some easy examples.

[Beingme]

User Story Example:
"As a shopper, I want to easily add items to my cart so I can quickly purchase them."

Use Case Example:
Use Case Name: Add Item to Cart

Actor: Shopper
Trigger: Shopper clicks "Add to Cart" button
Main Flow:
System displays product details.
Shopper clicks "Add to Cart."
System updates the shopping cart.

[njcanuck]

Uhhh in my experience the user story is at a higher level of detail than use cases. You wouldn’t break up a use case into user stories. Slip of the tongue? I work from top down at first. Would write up my user stories, then write use cases with more of the Interactive detail when needed. If working bottom up you could group use cases under a user story. Easy to miss requirements though and not intuitive for me. Would be interested in others’ understanding.

[kaneinkansas]

I can't believe they don't start with a Data Flow Diagram.

[antonpotuzhniy]

breaking use case into user stories, wait what?