Sometimes in Agile Projects I have been expected to create Use Cases to better define the interaction of the actor with the system.

Well, I will say from the beginning that Use Cases are, in my opinion, the antithesis of an Agile approach and, as much as they can be valuable, they cannot be easily applied to the concept of User Stories.

The textual description of a Use Case illustrates the sequence of steps in the interaction of the actor with the system. It usually includes a main flow (or main scenario) and a number or alternate flows that describe the exceptions to the main flow. To be useful and complete a Use Case requires quite a bit of details: all the possible options available to an actor when interacts with the system, all possible mistakes and issues, any business rules behind that activity. They are time consuming and require lots of analysis upfront, and still give a poor indication of the business value behind that functionality. Unlike User Stories, indeed, they do not say WHY that functionality is important to the user, making more difficult to prioritise it in the product backlog.


User Stories have been created exactly with this purpose: they describe which interaction the user wants to do with the system and why.

Let’s take an example:

“As a service provider, I want to enable the option of providing a service to client only after the Direct Debit request is completed, so that I can charge the client for service provided”.

The User Story describes a functionality and its purpose, clearing explaining the business value: I don’t want to provide a service to a client that I am not able to charge because of lacking information in the Direct Debit request.

That “so that” is the missing part of the Use Cases.

At the same time, it doesn’t provide a great level of details, yet. That is because of the nature of Agile, the details are defined when the User Story is prioritised like a “high business value” story.

This brings us back to the three “Cs” of the User Story’s life cycle:

Card: at the beginning the story is written down on a card, which allows for a brief description and a small level of details.

Conversation: as the project goes on there will be a number of conversation about each User Story, going deeper and deeper in the understanding of the business need and technical feasibility.

Confirmation: when the team agrees on the implementation of the User Story, the story needs to be completed with the User Acceptance Criteria, in other words, the conditions of acceptance to declare the implementation of the story successful. Without these criteria, the story is not ready to be allocated to a Sprint: the team hasn’t agreed what will determine whether or not the story is complete.

The most common format for these UAC is “given”, “when”, “then”.


“Given the customer hasn’t provided Direct Debit details,

When there is an attempt to allocate a service to this customer

Then the option is temporary disabled.”


Each User Story will have many UAC and all together they will successfully replace Use Cases, in my opinion.

A clear definition of the UAC is necessary for completing the User Story along with any other element that help to ensure that the right thing is built, such as screen mock up, workflow diagrams, technical notes, etc.

At the same time, it will allow the team to focus on priorities and define details as new information is learnt.


Leave a Comment

Your email address will not be published. Required fields are marked *