The terms “user story” and “use case” are often used during the daily business. But what do these terms actually mean? Do both mean the same? If not, what are the differences? Which term should we use?

During the daily business I’ve heard several opinions about these terms. Therefore, within this article, I want to explain the meaning, difference and purpose of user stories and use cases.

 
User story

A user story describes, from the perspective of the user, what the system should do. As a user story is based on the user’s point of view, it will always create a customer benefit. But it isn’t an explicit requirement. Instead a user story will often explain complex facts and therefore it will often result in a number of requirements.

There are several ways, rules and best practices to create user stories. In my opinion the following two basic concepts are significant because they reflect the common principles and best practices.

 
The CCC concept

According to this principle there are three elements: card, conversation and confirmation.

A user story should be written to a card. This explicit limitation to a small space of a single card is done because a user story should only contain short facts and no long explanations. This card is rather a reminder for a user’s which. It should lead to a conversation between end-users, developers, project leader and technical experts. Together they have to find out the real needs of the user and the way to fulfill these needs. Furthermore, during this conversation, the participants should talk about the confirmation process of the final implementation. For example they may define acceptance criteria or test workflows. These definitions can be used for acceptance tests during development as well as for a demo and handing over of the implemented solution to the customer. Furthermore the defined acceptance criteria will help the developer to better understand the user’s wishes.

 
The INVEST concept

This concept defines six basic criteria which must be fulfilled by a good user story. According to this concept a user story must be:

• Independent: It must not depend on other user stories.
• Negotiable: As described above, a user story is a reminder for a user’s which and it must be discussed in detail. So it should have room for adjustments and negotiations.
• Valuable: It will create customer benefits.
• Estimable: It must be possible to estimate the effort of the user story, as absolute value or relative to other user stories.
• Small: It should be possible to realize it within an iteration.
• Testable: There must be testable acceptance criteria.

 
Pattern for a user story

A user story can be written down in several ways. Following I want to show you a possible scheme.

• Title: It will help to identify the user story.
• Description: Short description of the users which. The following pattern may be used “As a <type of user>, I want <some goal> so did <some reason>.”
• Demonstration of user interaction: A short summary of the interactions, e.g. 1. system makes the following…, 2. User will do that…, 3. The system responds as… 4. …
• Acceptance criteria: The criteria to check and accept the implementation.

Advantages
If you make use of user stories, they will give you the following benefits:

• simple tool to articulate the project objectives
• understandable for all stakeholders
• definition of acceptance criteria
• allow project planning and project controlling as they reflect the scope and costs

Disadvantages

Of course, user stories will also have some disadvantages:

• the big picture is missing
• the absence of a predetermined level of abstraction may complicate the common understanding
• they will not help to understand complex processes

Use case
Beside the term “user story” you will also often hear “use case”. But what is a use case? Is it the same like a user story? No, it isn’t.

A use case describes the chronologic interaction with a system. This could be any kind of interaction and therefore it is not limited to a user input. The use case always starts with some kind of trigger and ends up in a defined result which gives a benefit. A use case is not interruptible. Thus he usually describes a process step and not a complete process. Therefore a use case does not have a clear relation to parent processes or workflows.

Start and end of a use case are defined through triggers and results. In most cases a longer interaction will be shown comprehensive, with all variants, branches, exceptions and possible results. Use cases are therefore usually more complex than user stories.

 
Advantages

An important advantage of use cases is their possibility to show the big picture. Use cases often arise from higher-level processes. So they normally have relations and can show workflows in an increasingly detail.

 
Disadvantages

Use cases are often only rough descriptions of process steps. Thus a detailed project planning and project management based on use cases is difficult. Furthermore they normally describe complex scenarios with a lot of branches and variants which usually cannot be implemented in one iteration.

 
Combination of user stories and use cases

As an attentive reader of this article you maybe say now: “Wait a minute. The disadvantages of a user story and the advantages of a use case are equal. So maybe it’s possible to combine both concepts.”

And that’s right. The concepts of user stories and use cases are neither equal nor contradictory. Rather, they are a perfect complement to each other as the individual disadvantages can be removed.

Use cases may be used for the process analysis and process planning. And user stories can be created from the use cases and then utilized for project planning and controlling.

 
Possible proceeding

In your daily business you can use the following combination of concepts. Please keep in mind, this is an example only. Your procedure is normally highly influenced and controlled by the guidelines, rules and concepts used in your company. Therefore I will only give you a very short overview about the idea of a possible workflow.

So, let’s say we have to plan and implement an ordering system for some kind of goods. At first we can start with the big picture and list all value adding processes. These could be things like customer management, order processing or accounting. In a next step you can split up the processes into sub processes. As described above, uses cases are your tool of choice to describe the sub processes. For example the “order processing” step may be break down to the use cases “Customer orders wares”, “Customer changes an order” or “Customer cancels an order”. At next and in our short example last step you will complete this hierarchic planning by defining user stories. You should analyze the use cases and create according user stories. For example the use case “Customer orders wares” could result in user stories like „As a customer, I can search for wares to look at them and to compare them.” or “As a customer, I can order wared to let them deliver to me”.

To summarize this short example, one can say that user stories and use cases may be used together to analyze and plan project tasks. The project goals can be shown in processes. At next the processes are described in more detail by using use cases. And based on the use cases it is possible to create user stories.

 
Features

As we now have solved the mystery of user stories and use cases I want to bring in a new term, the “feature”. But no fear, this new term will not destroy our actual world view. We might even get along very well without “features”. But it is often used in practice as general term by the project management or the customer.

A feature also describes a customer benefit or a functionality of a product. But the level and the scope of the functionality is not clearly defined. In the above example project we have seen processes, use cases and user stories. A feature can be anything of that. The implementation time, the effort and the detail level of features are thus very different.

Team members and departments with expert knowledge should avoid this unspecific term. Use it only when dealing with the customer because in this case technical terms like user story or use case will not be understood.

 
Summary

In the daily project business terms like “user story” and “use case” are often used without the knowledge of their real meaning, even by experienced developers. This article has shown the meaning, difference and usage of these terms. Furthermore these are not only two terms, these are very common tools for project planning and controlling. Therefore it is very useful and in my opinion mandatory to know and use these tools in a proper way.