Have you ever tried kayaking down a waterfall? This is quite similar to combining User Story and Use Case—Agile and Waterfall BA techniques.
Approaches to software project management differ a lot depending on the chosen product niche. In one case, businesses should act quickly and collect lots of feedback during product development to be able to better fit their product to user needs. In the other case, a large well-established product requires a lot of resources, planning, and coordination for its further development. So, it’s the niche of your product and its stage of development define which method you choose to manage the project and who wins the battle Use cases versus User stories in your company.
What User Story and Use Case are about
Let’s look at these two BA techniques closer to understand their strengths and weaknesses.
Use Case is a very basic business analysis technique for collecting functional requirements for a particular functionality in the planning environment. It has been in use for decades and is still popular in software development for well-established niches.
There are many formats of use cases, but in general, they are all about describing sequences of steps within a feature:
Actor does something—System does something.
Actor does something else—System does something else.
All interactions are well-structured and summarized, so you get a highly detailed and readable document with actors, flows of events, and post-conditions. However, this document is rather a technical reference for developers than a document for business people and stakeholders.
Below you can find one of the most common use case templates:
- Name. It should be short and informative.
- Summary. This point helps understand the main functionality of a particular feature.
- Rationale. It explains the logic behind the functionality and specifies the problems it solves.
- Actors. This point may include one or more actors which can be either other systems or users.
- Preconditions. This is the state of a system that is required before the use case can be started.
- Basic course of events. This is a linear sequence of interactions leading to the required result.
- Alternative paths. These are all other linear sequences of interactions within a particular feature.
- Postconditions. This is the state of the system after the use case is completed.
In the end, you get a fully described collection of functional requirements for a particular feature. Having this document, a developer team can implement this particular feature with all its exclusions, alternative flows, and possible inner events.
User Story is a business analysis technique for collecting functional requirements. It was created not so long time ago as a response to fast-changing markets and technologies. Being a part of the Agile approach to software development, User Story allows you to deliver priority-based business value to the project’s stakeholders. Let’s briefly overview the entire process to see how it works.
Technically, a user story (or scenario) describes one very specific need that a user has. It consists of 1-2 sentences written in a simple language that is easy to understand by users. Most often, a user story is written on a separate (index) card, but it can also be created in Google Sheets or any note application. For example:
Saving an uncompleted email
A user is composing an email but has to interrupt the process for something else. She saves her email as a draft to continue later.
Or here is the same user story but written in a little bit different format:
Saving an uncompleted email
A user is composing an email and wants to save it so that he can continue composing it later.
Formats may differ, but each user story should meet a set of common criteria to be efficient. To assess your user stories, you can use the INVEST checklist:
- Independent: it can be developed independently of others.
- Negotiable: its details can be worked out during an iteration planning meeting.
- Valuable: the described benefit has value to the customer.
- Estimable: you can assess how much time your team needs to complete the story.
- Small: it can be developed in one sprint.
- Testable: it can be unit and acceptance tested.
This acronym is easy to remember and useful for user story assessment. If each single user story satisfies all the criteria listed, they will work well together in the context of the entire project.
Thus, a user story describes not the feature but one of the user needs that should be satisfied with this feature. To see a bigger picture of the project, you still don’t describe its functionality but create a story map that contains all user stories you have created. The advantage of the story map technique is that you can group user stories by epic and order them by priority and time of delivery.
According to Mike Cohn (one of the Scrum Alliance founders), User Story has three stages or elements—The Three C’s:
- The Card is the initial stage. At this stage, a user story is a short and vague description of a user’s need. It remains in this stage until just ahead of when this piece should be delivered.
- The Conversation stage is the time when the user story gets details. The team should understand what and how should be done to deliver the value described in the initial card.
- The Confirmation stage is all about the Acceptance Criteria—how the developer team and stakeholders agree that the story is done.
Once the need expressed in a particular user story is covered, this user story is removed from the story map. And the time to implement the following user story comes.
|A user story is a one to two sentence description of a user need written in a natural language that is easy to understand by users.||A use case is a well-elaborated document describing a set of interactions between System and Actor. It contains all the functional requirements about a specific feature.|
|The user story structure is clear and simple: an actor wants [an action] so that [achievement].||The use case structure includes the following elements:
the goal of a particular feature and its short description,
the trigger (that initiate the use case),
flow steps (as well as alternative flows, and all possible exceptions),
and, finally, postconditions.
|Once it’s written, it is placed on a story map (into the context of the entire project) and gets its order and priority. Later it can be reconsidered and changed based on the changed user needs or the completed parts of the project.||Once it’s written, a developer can start developing the feature described in the document, since all the necessary details are provided.|
|A business analyst uses this tool to see a particular user need in the context of the entire project and be able to implement them one by one according to their priority and user’s feedback.||A business analyst uses this tool to create a document which lists all the functional requirements for a particular feature. So that a developer can start implementing it.|
|This technique suits you if you need to explore the market and get a lot of feedback from users.||This is a highly efficient technique for developing products in any well-established niche.|
|It is perfect for any Agile software development project.||It is perfect for any Waterfall software development project.|
How they work together
As you can see, User Story and Use Case are two different business analysis tools. User stories are used in an Agile environment, while use cases are a basic technique in a Waterfall environment. However, there is a lot of discussion about combining these approaches in Agile projects.
Technically, this is possible to use both of them within the same project. But it won’t be the Agile approach anymore since its logo is simplicity and flexibility. The essence of Use Case is to define all the functional requirements of a specific feature upfront. While the essence of User Story is to remain open to the change and be delivered on a just-in-time and just-enough basis. Using Use Case in Agile projects brings lots of compromising into the team and shifts the focus from solving needs to polishing what is already produced.
The bottom line
If your company works in a well-established and stable segment of the market and your product is familiar to your customers, your software development processes are rather linear and predictable. In this case, as a business analyst, you follow the Waterfall project management approach and collect functional requirements using use cases.
The situation changes if your product is new to the market. In this case, your team has to experiment a lot and collect as much feedback from customers as possible. That means you need to implement the Agile approach and User Story to develop your product by small increments at a cracking pace.
Combining these two approaches will complicate the development process, and you’ll waste time doing work that will never be used.