User Stories vs Use Cases


User Stories vs Use Cases

Classic Dilemma

User Stories vs Use Cases! Which one to use? Which one to use when? Which one is better? Which one is more suited for my project? What if I choose one method over the other?

As a Business Analyst you may have faced these questions during your career. Sometimes the answer is very clear and the other times there may not be a definitive answer. You must take a best guess and move forward. Before discussing the answers, first let’s review the concepts.

What is Use Case?

Use case represents requirement in the form of user interactions with the system. Use case is always written with a specific user goal in mind. Each use case must contain an actor and verb. For example, ‘online buyer’ is an actor and ‘add item to cart’ is a verb.

A use case diagram represents the scope of all the features of the solution. It follows Unified Modelling Language™ notation. Use case diagram comprises of several use cases that make the system altogether.

What is User Story?

User story is a business analysis artifact that is also user or persona driven. It describes the business need in the form of an ability user (or system) wants in the solution. It also must state why the ability is required and what the benefits of that ability are. It does not have any mandatory format though.

User story is part of the (product/project) backlog. The backlog in turn contains user stories/tasks (requirements) in a linear fashion. Backlog is usually prioritized from high to low, additionally with a ranking when priorities are the same. When it is prioritized by business value of the tasks/stories in it, it is called managed backlog. In many projects, user stories are also represented visually as a user story map, which is a structured visualization of a backlog. User story map is a map of user stories that are transposed from a linear backlog, onto a visual working board.

Each of this concept is a detailed topic in itself. For the context of this article, I will limit it only at the introductory level. Let's now look into differences and similarities between user stories and use cases.

Differences between Use Stories and Use Cases

1. Formal vs Informal:

Use cases are somewhat formal in their representation. The construct has specific elements such as primary and secondary users, per-condition, post condition, main alternate and exception flows etc.

User stories are informal in nature. Business analysts facilitate writing of it collaboratively. User stories are written in a natural language. Agile practices suggest a user story has persona, ability, benefits and acceptance criteria stated.

2. Waterfall vs Agile:

Use cases are generally used in projects that follow waterfall methodology. They are used when the requirements are quite clear thus enabling design, development and testing. Whereas user stories are tied to the agile world of product and projects. They are most suited when the requirements are more changing. They are used to define requirements iteratively.

3. User and systems interactions vs end-user driven:

User cases emphasize more of actor and its interactions with the systems and their inter-relations and dependencies. Whereas user stories are end-user driven and are used to agree on what users need and how the feature will benefit the user. The UX and UI and interactions are later developed keeping those needs in mind.

4. Detailed level vs any level:

In case of user stories, the requirements are iteratively defined and are defined at level 1,2,3 etc until there is clarity to the requirement. Whereas for use cases, there is no such level. Use cases are already at the detail most level.

5. Heavy emphasis on traceability vs heavy emphasis on acceptability and on testing:

Use cases put heavy emphasis on structure and also on traceability from the business requirements to among other use cases. Whereas user stories put lot of emphasis on what and how the testing will occur, what will define the acceptance of a given user story.

Similarities between Use Stories and Use Cases

1. Both represent ways to state requirements:

Well, this may sound trivial but the point is, both of these are very useful and proven ways to capture requirements. Both of these are a great requirement analysis and documentation tool for a business analyst. There is no such thing as one weighs more over the other. Just that each one is more useful in certain situations.

2. Both enable stakeholders and BAs to ask questions

Both enable teams to ask questions in a certain direction and assist BAs to move towards clarity. The constructs or template elements of a use case or a user story are simple cues to enable business analyst with asking specific questions to the stakeholders.
Questions or elicitation activities lead to further information and you will get further insight into stakeholders’ needs. Hence both use cases and user stories are helpful in discovering actors, verbs, steps, outcomes etc.

3. Both are verb or action oriented:

User stories and use cases are action oriented. They represent steps or an active voice and forces or enables business analysts to capture user interactions and system responses.

4. Both do have user focus in mind:

Last but not the least, user stories may seem to be more user focussed. However, both use cases as well as user stories have their own place in business analysis work. Both of these do put user focus in mind.

Comparative Examples

Below are simplified examples of the same requirement ‘booking a movie ticket online’ using Use Case as well as using User Story format.

Use Case Format

Use Case Name: Book a movie ticket
Use Case ID: UC_001
Business Req Ref: BR_005
Primary Actor: Customer
Secondary Actor: Payment Gateway
Pre-condition:  -
Trigger: Customer comes to the booking platform with the goal of booking a movie ticket in a given city
Use case description: This use case comprises of the flow of steps a customer (end user) takes to search for movies, selecting a movie in a given city and at a given timing and then proceeds to book the ticket. Customer gets ticket confirmation in the end.
Basic flow:

1. Customer visits the movie ticket booking platform and enters name of the city

a. System shows current and upcoming movies with their names and timing/theatre information

2. Customer selects specific movie from the list

a. System shows the more information about the selected movie

3. Customer proceeds further to check availability for a selected show timing

a. System shows the seat availability chart for the selected show timing for the specific movie/in a given theatre in the select city

4. Customers selects the seats and proceeds to book

a. System confirms the seat selections and takes the user to make final booking

5. Customer enters payment information

a. System connects with the payment gateway and confirms the transaction

b. System sends customer booking conformation details via email/registered phone.

Alternate flows:

1. Customer enters payment information that is invalid

a. System notifies the user of this and redirects him/her to provide payment information once again

Exception flows:  
UI References: UI_Mockup_Ref1


User Story Format

User Story Title:

As a customer I want ability to book a movie ticket that matches my preferences so that I get to quickly and easily book the movie of my choice

User Story Description:

This feature will involve user selecting a specific city, searching for the movie name, selecting a specific timeslot and then completing the order booking formalities.

UI Sketches/UI references:




Acceptance Criteria:

  1. User navigates to the search movie page
  2. User selects city
  3. User enters movie name
  4. System searches for the matching movies and displays results
  5. User selects specific movie timing and proceeds to book
  6. User enters no. of guests and seats
  7. User provides payment information
  8. System validates the payment information and confirms the booking
  9. System sends email/SMS to the user with booking confirmation details


  1. This user story can potentially be broken down into more detailed user stories of level 2,3 and for each level2,3 user story (we can call it an atomic user story), we can write acceptance criteria at that level.
  2. Note that above stated use cases and user stories are for demonstrating the differences and similarities only. Real life requirements will be very unique to the product/platform you are working on. Those requirements will also contain a lot more detailing.
  3. You can find online many good examples of use case diagram and use cases. Especially on drawing tools’ websites such as Lucidchart are pretty good.

Concluding Note

In a nutshell, there are many differences between use cases and user stories. There are several similarities as well. Both of these techniques can even be combined at times to make the best of both the word. I would like to give a recent analogy from my trip to the Himalayas. Both of these techniques are like two rivers (the river Ganga and Yamuna) that flow through the Himalayan ranges and then they join together to become the river Ganga. Name does not really matter. The river which is deeper gets the name after merger. Each river still emphasizing the collaborative existences in the nature!

Thoughts? Would love to hear your experiences and ideas.

Swati PitreAuthor: Swati Pitre, CBAP®, is Sr. Business Analyst 

Sr. Business Analyst, Consultant and Trainer with 20+ years of industry experience across various domains and geographies. Recognized by clients as a valued member of business and technology teams, with a proven track record of delivering artifacts and solutions of high quality. Recognized by participants as a highly effective and hands-on trainer and coach. Self-starter, process-oriented, and creative with unique problem-solving skills.

Her specialities include Process Improvement, BPM, Predictive Analytics, Product Development, Quality, and Governance. She undertakes various training courses such as CBAP®/CCBA®/ECBA® Prep Courses, Comprehensive BA Job oriented Course, Agile BA Course, and several other customized courses.

She is also a public speaker and has completed Level 3 of Effective Coaching Pathway at Toastmasters International. She is a yoga and fitness enthusiast with varied hobbies include reading, writing, art, travelling and music.

LinkedIn: Swati Pitre, CBAP® | LinkedIn

Like this article:
  24 members liked this article


mark barratt posted on Wednesday, August 17, 2022 1:53 PM
I nearly gave up after getting as far as "Use cases are generally used in projects that follow waterfall methodology". Use cases are ideal for iterative development and were instrumental in the advancement of smaller iteration development methods in the late 90s, although all development has been based on some level of iteration since time in memoriam. There is not - and never has been - a bonafide "waterfall methodology". My view is that user stories are generally less vigorous versions of use cases. They have their place when developing solutions that are small on not very critical or where the Dev team is mature and fully understands the system AND the business context. Use better suited for critical systems and immature or 3rd party Dev teams but they can lead to over analysis and unecessarily complex documentation.
Gary Woody posted on Friday, August 19, 2022 5:53 PM
I found this explanation beneficial for my new (younger) business analysts that are developing these types of artifacts for the first time in a large project. It comes down to your audience. We tie process flow diagrams to the Use Cases only. Business subject matter experts prefer Use Cases. Front line Users that participate in research and investigative interviews, as well as UAT, much prefer User Stories. Both types are made available to vendors for ROM estimates, and both are provided to the Agile dev teams who prefer the User Story format since it includes the acceptance criteria.
Istvan Danyi posted on Sunday, August 21, 2022 2:48 AM
This summary is good attempt to collect all these characteristics, but I missed mentioning the graphical notation which UC has (ie. UML), but US does not have. This notation sometimes is useful.

However, I totally do not agree with the statement that the use case specifications have not different levels of granularity. I would distinguish at least 3 levels: draft, basic (general), detailed. If you would like to apply this technique in a project, the first step is to collect a list of UCs including only a purpose. This draft level provides the input for further requirement analysis. The full detailed level is required only by some UCs of the complete requirement package. For example, in many cases, most of the alternative/exceptional flows could be specified with only 1-2 sentences as well.
Istvan Danyi posted on Sunday, August 21, 2022 3:04 AM
In general, I would say that the different terms of UC and US were risen purely because of historical reasons and human nature. Many professionals (including me) prefer to believe in introducing new terms could solve their problems which you understand at the time. It will not. At the end of the day, you will meet the same problems, so you must investigate them deeper and deeper. What a surprise! Your solution will be more and more complex (i.e. “formal”) and apply very similar solution elements (alternative/exceptional flows : separate additional stories, actors : personas, spec. requirements : acceptance criteria). During this journey, you strictly watch to use always different terms to prove that is still a reasonable different technique. Of course, this attempt can contain enhancements including better terms as well. However, IMHO it would be more efficient if we did not want to build approaches often from the ground and then tried to explain valid differences. We would rather revise/enhance the existent ones.

This is true for UC and US. I would not propose to choose from them, for example depending on the current project environment is agile (adaptive) or “waterfall” (predictive). I think you can use both with reasonable adaptation and extensions. I propose to know and understand both, and do not insist on either of them. Hope this article helps to achieve this.

And finally, please do not start building total new set of terms for these. Moreover! Let’s consider to merge one to another, so we may speak the same term for the same problem without additional mapping/comparison. OK, I stop it…
djf posted on Friday, August 26, 2022 2:47 PM
My experience has been US are easier for people to understand. We use the following template to capture US...As a [type of user], I want [an action] so that [a benefit/a value]. We like US to be INVEST-able. And don't forget the acceptance criteria (AC). AC is very important.

There is an art to UC and a format (UML). My experience has been UC is harder to pick up. There should be training provided to all that will use UC so that the team follows the same format. This is where teams ran into problems because team members weren't following UML and UCs were all over the place and very hard to understand. I like to start w/ a UC diagram and then go from there. I write UC to support US.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC