What is User Story? Learn how to write

When we create or develop software it is necessary that it is as explained as possible in the user’s language so that it can be used in the best way. In this sense, using the user story concept becomes essential. Did you already know him?

It is part of a stage in a more agile structure for developing and implementing a product in different sectors, such as information technology.

It is a complement to the Scrum framework and should always be prioritized in teams that work to understand what problems users are facing in a software and how to find the simplest way to solve them.

Continue reading to understand more details about it , as well as its importance and how to use it in your daily life. Let’s go?

Table of Contents

What is User Story?

It is nothing more than a tool to define and organize the requirements of a system and make it more readable for users, being widely used in agile methodology and IT.

But how does it work? When you create a product or project, it needs to be as simple as possible for a layman to understand, otherwise what’s the point in trying to offer it to your customers and users, right? The user story that makes this adaptation is an essential characteristic of Agile development .

We can say that it is a kind of promise of conversation with the user, where written specifications are placed using business language, exemplifying, in a simple way, how a person would use a certain functionality of a product.

Thus, its most used format is this:

As a <role>, I want <desire> so that <benefit>

Being:

Role : is the persona, for whom you are creating this requirement;
Desire : the persona’s intention, not the resources they use;
Benefit : what will he gain from it? What does he intend to achieve?

Because it’s important?

To explain this, imagine a situation: you have a car shop and you are selling 3 of them to different people. Only that on delivery one came without air conditioning, another without a reverse sensor and the other came complete, but there was some defect in the engine in less than 5 km.

These failures may be the result of not mapping user needs and checking what the user story would be showing if it had been done well.

Therefore, it only works as a kind of reminder of what details are needed in a project , and with it alone it is not possible to develop the users’ story, you need documents and more details for that.

However, its role is to keep the user needs written simply and help guide the conversation between the people who will build the functionality they describe.

Thus, it serves to prioritize customers and estimate the effort required to achieve the objectives proposed in a product or project.

Once the user story is documented, the development team knows why it needs to develop, after all it is a way to generate value in its execution. Therefore, it is important because it helps define the end user’s desire and increases the assertiveness of the entire team’s work.

How to write user stories?

First, the most relevant point is to understand that user stories need to be simple and objective, to be easy for developers to understand.

If they get so long that they don’t fit in a frame, you need to refine them.

User stories are descriptions of your product’s functionality and, for this reason, it is important that they truly represent the user’s point of view. Therefore, it is necessary to document them in three blocks:

1. Value delivery

Here you should think about how to relate user stories to delivering value. As? Understand the reasons why stories are important, what users want, among others.

Once this question has been answered, you must include in the description of this documentation the objective of the main functionality in “Market Value”, “Risk Reduction” or “Increase Capacity” and what the details are.

2. User narrative

The second step is to create the narrative of these user needs. Then you can use the template already mentioned, such as:

How to… [feature target]
I want… [desired item – title]
So that I can… [delivery of value – job to be done of that]

3. Technical requirements

In the third block you will describe the technical requirements. In other words, it will outline what needs to be done to meet the proposed needs and objectives.

To do this, it is possible to use the 7 product dimensions technique, which are:

actors
Interfaces
Action (user story)
Data
business rules
Environment
Quality (acceptance criteria)

3C’s User Story Template

As briefly mentioned in another topic, there is a concept called the 3 C’s , which indicates how to build your user story.

Let’s say you are a Product Owner and, together with your Scrum team , you start your Product Backlog and create a user story for each item. You should use:

Card

Here the idea is to describe the story in a simple short form , with everything having to fit into a small card size.

Therefore, you must define: who the main actor is, the persona, what the main objective is and the justification for it.

conversations

They are like meetings, where everyone on the team debates plans to make the goal happen.

At that moment, it is expected that people, together, read the User Story and clarify as much as possible the understanding of what is expected, bringing to discussion what are the possible problems and solutions.

Confirmation

Always use criteria to identify whether the story is truly finished. Here, scenarios are created that, when executed, show whether the described results are obtained and whether everything is ok, otherwise it will be returned to the development team to correct the bugs.

INVEST

In addition to the 3Cs, another important method is INVEST, which will help you evaluate the quality of your user story , which aims to use each acronym to see if your story is indicating all these factors: independent, negotiable, value, estimable, small and testable.

Granularity of User Stories

Understanding the entire conceptual part, it is time to find out about the structure. There are some types of granularity required for backlog items to be refined and eligible. They are:

The triad Epic, Feature and User Story are the most used artifacts for structuring the product backlog (product backlog) and for use in the sprint backlog (sprint backlog), being:

User Story

The clear and informal representation that expresses the need and/or requirement of a potential user. It’s part of an ultimate goal.

Functionality

It is who groups a set of user stories, with the function of the Product, which contains several functional requirements with their rules and exceptions.