User Stories in development

What a User story is

In product development and management, a user story is a simple and understandable description of one or more functions of a software system.

A user story describes the type of users, what they want and why. This tool helps to create a simplified description of the requirements, but it is not a requirement itself. Requirements are a different tool, with a more complex structure and description.

Usually, the User story is used when developing using the Agile methodology. Earlier, we wrote about how the work takes place with a flexible approach. At the discovery phase, product development is usually split into user stories, and not into characteristics or requirements.

Why User stories are necessary

User stories are a planning tool. With their help, we determine priorities, evaluate and decide at what stage (sprint) this or that functionality will be implemented.

The user story is useful because it simplifies communication. Instead of exchanging documentation, a dialogue begins on each new feature. Thus, there are fewer misunderstandings, the work is carried out transparently, and the result is accurate.

The power of user stories is that they start a dialogue. Instead of just taking a specification and passing it to colleagues, which is interpreted first by developers, then by testers — we start a discussion. We include employees with different communication skills. And so for each new feature.

User stories Advantages

• Short and clear. It is easy for each participant of the process to understand.
• They allow you to break the project into small stages and show visible results at each sprint.
• The team focuses on the needs of real people, not on abstract objects.
• Allow developers and clients to discuss requirements throughout the project life
• They are suitable for projects where the requirements are changeable or poorly understood.
• Simplify the assessment.

What the user history looks like

Most teams use a user history template, usually, it’s just one or two sentences written using the following formula:

How [user description], I want [ functionality ] to [ benefit ].

Let’s have a detailed look at the template:

Description of the user. Who is the person on the other side of the screen? The identity of the user story does not necessarily have to be limited to the person’s position. For example, the head of a remote team can be either a department manager, a CEO, or any other person in the company. When building a story, we must understand how this person thinks and works, know his intentions. Ideally, users should be interviewed.

Functionality. It describes not the feature itself, but the intentions of people, and what goals they want to achieve.

Benefit. Why do users perform all these actions? We describe the final benefit and the problems that the chosen person wants to solve.

Examples of user stories

In practice, user stories may look like this:

• As a database administrator, I want to automatically merge datasets from different sources so that it is easier for me to create reports for my internal clients.
• As a brand manager, I want to receive notifications whenever a reseller advertises our products at prices below the agreed prices so that I can quickly take measures to protect our brand.
• As the head of a remote group, I want to include file sharing and annotations in our team messaging application so that my team can collaborate in real-time and keep an archive of their work in one place.

Note: Different users described in the stories may be the same person who needs different functions for different tasks.

Why we use User story

Instead of writing plans from the point of view of the product (what functions need to be created), User stories deploy us to users. This tool forces you to compose each proposed idea for new functionality from the point of view of real people who will use this functionality. In this way, we create a better interface for users of the future product.

The use of user stories also reduces the time and budget spent on creating comprehensive documentation, makes the work easier and clearer.