What is a User Story? How (and why) to write one

By Virginia Fabris

Published: 28 April 2025

User Stories are a central tool in the collaboration of agile teams. Their field of application is very broad and ranges from satisfying specific customer needs to supporting Scrum teams.

But what exactly is a User Story and how is it realised? In this article we will shed light on this concept: we will show you how a user story should be structured and how to work successfully with this tool.

See all software Operations Management

Discovering User Stories

User Story: definition

UserStory is an English term that can literally be translated as ' user story'. In the field of agile project management and software development, the User Story is a tool for describing the functionality of a given system from the perspective of the user experience.

What is it used for?

The function of the User Story is to meet specific user needs and expectations regarding certain functionalities of a proposed software or solution.

The purpose of the user story is to make the reader understand the benefit of the system under consideration. In this way, a higher degree of awareness of the benefits of the product or service presented can be achieved.

A User Story ultimately serves, therefore, to increase the understanding of a system and, thus, to boost its degree of success among users.

User Story vs. Use Case

The Use Case, or use case, can be considered as a more massive version of the User Story. In fact, it is very elaborate and detailed, covers a wider context and is, therefore, more comprehensive than a User Story. It usually even comprises several User Stories.

The use case is normally more durable than a User Story. In fact, it is usually maintained throughout the development of the system, while the User Story disappears upon its completion in a Sprint.

Writing a User Story

Who writes it?

User stories can be written by or for users.

How is it written?

Normally the User Story is written by a team, which is dedicated to writing and optimising it. Usually the team focuses, first of all, on developing certain criteria around which to develop their story. These may be, for instance, the degree of complexity, the model to be followed, the layout of the information, and so on.

From the outset, therefore, the structural properties one wishes to attribute to the story must be defined. If you are working in a team, you should divide the tasks within the group and fix the time frame in which the work is to be done.

To begin with, Story Points must therefore be established, i.e. arbitrary numbers used to estimate how much work the team is able to complete in each iteration.

Then, Sprints, i.e. work cycles lasting from one to four weeks, must also be set. The set of Story Points and Sprints form the basis of the User Story Planning.

☝ In this context, Sprints have been referred to in the plural. However, it should be noted that only one iteration or Sprint is often necessary for the realisation of a User Story.

The next step is to ensure that tasks are clearly expressed and assigned to different team members. Organisation and coordination are, in fact, crucial in order to write a quality User Story.

However, it happens that User Stories are written without a detailed analysis of the tasks. The degree to which the story is structured is, in fact, an arbitrary factor and subject to the free choice of the team. Clearly, the more a team aims to guarantee excellent services, the more it will favour articulated planning of the User Story.

☝ The purpose of User Story planning must be the benefit of the user, not the promotion of the solution, product or service under consideration.

How do we proceed?

User stories are managed in the Backlog. This is where the DEEP concept, developed by Roman Pichler, comes into play. He devised this model in order to operate a correct Backlog. DEEP is an acronym, which stands for the following words:

Detailed Appropriately: high-priority user stories should be formulated in more detail than low-priority ones.
Estimated : User Story components should be estimated, especially in relation to Story Points. Knowing, even if only approximately, the constituent elements of a story helps to prioritise and track the release project.
Emergent : the User Story has a dynamic character. In fact, it evolves and its content may change frequently. New elements may emerge based on reader ratings and feedback. On this basis, user stories need to be modified, updated and optimised.
Prioritised : story components or stories themselves with a high priority should be implemented first.

What approach should be given to a User Story?

When you are in the process of writing a user story, it is good to keep a basic recommended structure in mind:

As x (role of the writer), I would like xy (reference to the desired functionality), in order to yy (purpose).

In addition to this basic model, other alternatives exist. Another possible model for a user story is, for example:

In order to yy (purpose), since I am x (role), I would like xy (functionality).

☝ The role must be made to match your Personas. A Persona is a typical representative of your target group.

User stories, like all stories, can vary in the degree of detail provided. Indeed, some stories may merely provide very rough content. Others, on the other hand, may present a generic beginning, only to be refined later on. Still others may be detailed from the outset.

Following a template to formulate one's User Story is not mandatory, but it is practical. Experience in the field of user stories has shown that keeping to the recommended basic structure not only aids formulation, but also facilitates reader understanding.

What language should be written in?

The preferred language for writing a User Story is English. This might be a strange choice, especially if you are active in the Italian scene. However, English has long since become the lingua franca in almost all countries and is now spoken internationally.

What is more, this language allows a high degree of conciseness, since it is extremely concise and direct.

This is why it can be a sensible choice to present one's User Story in English.

User Story Examples

Below are some examples of the application of the proposed user story models.

1. As a lover of historical novels, I would like to be informed about relevant books coming out, in order to be able to order them in time at the bookstore.

2. As a lover of adventure films, I would like to know what films of this genre have been released in your cinema, in order to be able to buy tickets online.

3. As I am a cinema lover, I would like to know what promotions are available in your cinema so that I can find an affordable subscription.

Tips for a quality User Story

Since the User Story aims to be received and understood in the shortest possible time, it is important that it:

Is written using short, incisive sentences;
Contains simple and unresearched vocabulary;
avoids technicalities: people without any specialist background need to be able to understand what they are reading;
Focus on providing direct answers to the questions: who wants what from the system? Why does the user use the system (for what benefit)?

In the words of Mike Cohn, one of the main contributors to the invention of the Scrum software development methodology, all agile user stories include only one or two sentences written in a simple manner and, most importantly, a series of conversations triggered accordingly on the desired functionality.

Management tools: acceptance criteria

One can be sure that a user story has been fully implemented when the acceptance criteria prove to have been met. But what are acceptance criteria?

By acceptance criteria with reference to a user story we mean defining the parameters that demonstrate that the key results of the user story have been achieved.

The parameters we are referring to are the W-Questions (Who? What? Why? When? Where? etc.).

These make it possible to understand whether a User Story is effective and meets all possible cognitive needs of the reader.

Acceptance criteria are, therefore, tests that are applied to the user story to check its appropriateness according to the purpose of use. Particular attention in this context must be given to the identification and enhancement of keywords, i.e. the use of relevant verbs, adjectives and nouns.

The INVEST principle

One way to test the effectiveness of your User Story is to use the principle formulated by William Wake. INVEST is also an acronym and stands for:

Independent: the User Story has its own individuality and is independent of other User Stories.
Negotiable: the content is implementable and continuously improvable. It is developed by a collaboration between the reader and the makers of the story. It can thus go into more detail as its realisation and testing progresses.
Valuable: the user story must be of value to the customer. It must offer the reader an advantage or benefit and provide indications on how to achieve it.
Estimable: the evaluability of a user story is the prerequisite and condition for its being negotiable. The evaluability of a user story also depends on its size: the longer a story is, the more difficult it will be to evaluate. Not only that, this criterion also depends on the experience of the team: a group of experts will be able to evaluate a story with more skill and immediacy than novices.
Small: quality user stories tend to be short. By the way, the shorter a story is, the more evaluable it is.
Testable: the user story has acceptance criteria and can be tested. If a story is hardly testable by users, this may mean that it is not clear enough, or that it does not offer a valuable benefit to the reader.

Ultimately, all the points of the INVEST principle serve to assess the quality of a user story and also to pilot its realisation so that it is effective. Following the points proposed in this model can make all the difference in determining the success of your User Story!

The User Story Hierarchy

As the INVEST principle makes clear, user stories should be independent of each other. However, in practice, it is often the case that interdependencies exist between various User Stories. The dependency of User Stories can be of different types. For example, it may be at the level of content, technical, regulatory or normative, temporal, and so on.

The existence of interdependencies between User Stories is often not evident, which is why it is useful to use User Story Mapping in order to uncover and remove them.

User vs. Epic Stories

There is a basic differentiation within the macrocategory of user stories. In fact, depending on the extent of the benefits they provide to the reader, User Stories can also be called Epic Stories.

The differentiation of these two categories is not homogeneous and always the same. This means that there is no recognised standard according to which a story is automatically classified as User or Epic.

Generally speaking, however, an Epic Story can be defined as a user story that possesses a high degree of technical and specialised poignancy. Epic Stories, in fact, normally describe functionality in an absolutely detailed, technical and specific manner.