Get certified - Transform your world of work today


User Stories and Use Cases Combined

A combination for disaster?

17 August 2015

Rumesh Wijetunge
Zaizi Asia

Organizations adopting Agile for the first time run in to the problem of which requirements documentation method to use. Development and QA teams are so used to having requirements spelled out line by line that they ask for use cases even in Agile projects.

So, what is the purpose of a user story and of a use case?

A user story is a method of documenting requirements from a user's needs perspective, detailing the role of the user who interacts with the system to gain a certain benefit. User stories do not detail how the goal is obtained step by step, but the team may use acceptance criteria to list how they consider that the goal was met.

The purpose of a use case is different. A use case defines a step-by-step user path -- the system interaction that will result in a certain goal being obtained. Use cases are normally used to document requirements of process flows that are fixed and do not change often.

So when does the marriage between user stories and use cases happen? Or can it happen?

In Agile, when both user stories and use cases are used together, ideally there should be a mapping between the user story and the use case. It would not be a one-to-one mapping (one user story mapped to a use case). For example, let's assume there is a method of carrying out a certain work flow in three different ways. So there would be one main flow plus two alternate flows in a use case. But all three flows are detailed in one use case. There can be an epic that covers these three scenarios, but the team can decide how many stories are required to meet the requirements specified in the use case. For example, it may be three user stories mapping to the three alternate scenarios to start off with, which may further be broken down into more granular-level user stories.

Organizations are striving to find a proper match or identify a proper use of Agile and Waterfall modeling tools. It is best to use whatever tool you can as long as it improves and eases the project team's day-to-day activities, and as long as it increases the visibility of the tasks being carried out among team members.


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.5 (2 ratings)


Rohit Ratan Mani, CSP,CSM, 8/17/2015 7:05:12 AM
If we write Aceptance Criteria in Given-When-Then format we might cover different Use Cases.
In my view:
User Story + Acceptance Criteria = Use Case
I am open to suggestions.
Rumesh Wijetunge, CSP,CSM,CSPO, 8/20/2015 7:55:47 AM
Well user story + acceptance criteria may be one full use case or part of the use case. Why I am saying this is a user story may only cover only one scenario or flow of actions (primary or alternate flow). Plus we need to make sure that all business rules, field validations etc are covered in the acceptance criteria.

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