What is User Story and how to write it

User Story is an informal, general explanation of software functionality written from the perspective of the end user. Its purpose is to describe what value the software functionality brings to the customer. It formulates not only the business value but also the requirements for development and testing. User Story is called so because it is created through storytelling, like a story.

We can also find another definition: it is a tool that helps customers understand what they need. 

A key component of agile software development is prioritizing people, and the user story puts end users at the center of the entire process. These stories don't use technical language to create context for the product development team. After reading the user story, the team understands what they are doing, why they are doing it, and the value of the product they are building.

An example of the format can be summarized in a short sentence like: «As a [person], I [want to], [so that]». This is how the user/customer explains what they want and why.

Now let's look at this template in more detail to make it clearer how a User Story should sound:

«Person» – who are we creating it for?  

«Want to» – this describes people's intentions, not the functions they use. 

«So that» – what is the goal or problem to be solved? What is the overall benefit to be achieved?

The text of the User Story itself should explain the role/actions of the user in the system. Even though the user story plays a role that previously belonged to requirements specification, use cases, etc., it is still significantly different in several subtle but critical ways:

• User Story is not a detailed description of requirements, but rather a narrative representation of intent;
• it is short and easy to read, understandable to developers, stakeholders, and users;
• represents small increments of valuable functionality that can be implemented within a few days or weeks;
• efforts required for implementation can be quickly determined;
• user history is not stored in huge, cumbersome documents, instead, it is structured into lists that are easier to organize and reorder as new information becomes available;
• it is not detailed at the beginning of the project. This helps to avoid delays in development, piling up of requirements, and overly limited task formulation;
• it requires minimal or no maintenance at all and can be safely canceled after implementation.

How to write a User Story?

First of all, it should be written in compliance with spelling and grammar rules.

When writing a user story, it is necessary to avoid accidentally writing technical specifications.

User stories contain only the most important elements of the requirement:

• Who is it for?
• What do you expect from the system?
• Why is it important?

There are many recommendations for writing a User Story. The main ones will be discussed below.

Practical tips for writing user stories: 

• it's better to write many smaller stories than a few cumbersome ones;
• it's better to write with a whole team to avoid losing the nuances that are important for the product, business, and users;
• each story should be written without technical jargon;
• the user's needs should be accurately described;
• stories should be written the way they can be tested;
• tests should be written before the code;
• it is better to avoid UI as much as possible. Stories should be implemented without reference to specific elements; 
• each story should include a complexity estimate, as well as the time required for implementation;
• the story should have an ending, i.e., a specific result;
• the story should be clear to all project participants;
• User Story should comply with the INVEST model.

Next, let's look at the INVEST mnemonic in more detail – the criterion of a good story:

• I – independent – can be implemented in any order, i.e. independent of other stories;
• N – negotiable – reflects the essence, not the details; does not contain specific implementation steps;
• V – valuable – important for customers, business and stakeholders;
• E – estimable – estimated by complexity and labor costs;
• S – small – compact, can be done by a team in one iteration;
• T – testable – one that can be tested (checked), has acceptance criteria.

To sum up, a User Story is a short and clear description of a product's functionality, features, or the benefits that a user receives. It is quite difficult to assess its usefulness and relevance, since it is not directly involved in the development process, but rather serves as a starting point. User Stories can be checked for quality using INVEST criteria. It is mainly a way to start a dialogue without clear markers of its completion. It is useful in the first place because it helps the developer to better understand the product, the industry, and the target audience. And finally, its relevance is assessed by identifying and processing user needs with the product meeting these needs.