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 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 a use case?
A use case represents a requirement in the form of user interactions with the system. A use case is always written with a specific user goal in mind. Each use case must contain an actor and a 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. A use case diagram comprises several use cases that make the system altogether.
What is a user story?
A user story is a business analysis artifact that is also user or persona driven. It describes a business need in the form of an ability a 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.
A user story is part of the (product/project) backlog. The backlog, in turn, contains user stories/tasks (requirements) in a linear fashion. A backlog is usually prioritized from high to low need, with an additional ranking value when they share the same priority. When a backlog is prioritized by the business value of the tasks/stories in it, it is called a managed backlog. In many projects, user stories are also represented visually as a user story map, which is a structured visualization of a backlog.
Each of these concepts is a detailed topic in itself. For the context of this article, I will limit it to the introductory level. Let’s now look into the differences and similarities between user stories and use cases.
Differences between user 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 flow, alternate and exception flows, etc.
User stories are informal in nature. Business analysts facilitate the writing of them collaboratively. User stories are written in a natural language. Agile practices suggest a user story has a persona, ability, benefits and acceptance criteria stated.
2. Waterfall vs agile:
Use cases are generally (not a rule though) used in projects that follow waterfall methodology. They are used when the requirements are quite clear thus enabling design, development and testing.
User stories are tied to the agile world of products and projects. They are most suited when the requirements are developing over the course of a project. They are used to define requirements iteratively.
3. User and systems interactions vs end-user driven:
Use cases emphasize an actor and its interactions with the systems and their inter-relations and dependencies.
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 the 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.
For use cases, there is no such level. Use cases, as a final product, are already at the most detailed level.
5. Heavy emphasis on traceability vs heavy emphasis on acceptability and testing:
Use cases put a heavy emphasis on structure and traceability from the business requirements to other use cases.
User stories put a lot of emphasis on what and how the testing will occur, and what will define the acceptance of a given user story.
Similarities between user stories and use cases
1. Both represent ways to state requirements:
This may sound trivial, but the point is, both of these are very useful and proven ways to capture requirements. Both of these are great requirement analysis and documentation tools for a business analyst. There is no such thing as one having more weight than the other. It’s 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 analysts 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 force or enable business analysts to capture user interactions and system responses.
4. Both do have a user focus in mind:
Last, but not the least, user stories may seem to be more user focused. However, both use cases and user stories have their own place in business analysis work. Both of these do put the user focus in mind.
Comparative examples
Below are simplified examples of the same requirement ‘booking a movie ticket online’ using the use case and user story formats.
Use case format
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/theater information
2. Customer selects specific movie from the list
a. System shows more information about the selected movie
3. Customer proceeds further to check availability for the selected show timing
a. System shows the seat availability chart for the selected show timing for the specific movie in a given theater in the selected 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 confirmation 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
User story format
User story title:
As a customer I want the 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 time-slot and then completing the order booking formalities.
UI Sketches/UI references:
UI_Mockup_Ref1
UI_Mockup_Ref2
UI_Mockup_Ref3
Acceptance criteria:
- User navigates to the search movie page
- User selects city
- User enters movie name
- System searches for the matching movies and displays results
- User selects specific movie timing and proceeds to book
- User enters no. of guests and seats
- User provides payment information
- System validates the payment information and confirms the booking
- System sends email/SMS to the user with booking confirmation details
Note:
- This user story can potentially be broken down into more detailed user stories of level or 3 and for each level 2 or 3 user story (we can call it an atomic user story), we can write acceptance criteria at that level.
- 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 detail.
- You can find many good examples of use case diagrams and use cases online. Especially on drawing tool websites such as Lucidchart.
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 worlds. 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. The names do not really matter. The river which is deeper gets the name after the merger. Each river still emphasizes the collaborative existence in its nature.
Thoughts? Would love to hear your experiences and ideas.
Author: Swati Pitre, CBAP ®, is a 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 specialties 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 4 of Effective Coaching Pathway at Toastmasters International. She is a yoga and fitness enthusiast with varied hobbies include reading, writing, art, traveling and music.
LinkedIn: Swati Pitre, CBAP® | LinkedIn
Originally published at https://www.modernanalyst.com.
