What are User Stories and Why Write Them?

Using a user story is an important part of the Agile approach to software development. If you do not quite understand the meaning of this term, it can be simply defined as:

User stories – a description of what the user will do when interacting with your product, whether it is a website, an app or some software. That is, this refers to a scenario of interaction.

They are short and simple to understand, since the product is viewed from the perspective of a person who expects to receive a certain result from the interaction. A unique feature of the user story lies in using natural language and simple formulations, and the user stories’ format can be very different.

In the SCRUM methodology, scrum user stories are written (or approved) by the product owner. For customers (or users), they are the main tool for influencing software development.

The basis for the user story template formulation is the answer to these three questions:

• Whom do we do this for, who is our user? [type of user]
• What is he going to do and what are his intentions? [some goal or feature]
• What does he want to achieve and how will he benefit from it? [benefit, value]

As a result, we get the following construction:

• As a [type of user], I want [some goal or feature], so that [benefit, value]

The difference between a use case and a user story is that the use case is a list of actions, the scenario by which the user interacts with the system, and is used to perform an action or achieve a specific goal.

User Stories Examples

Even if you understand everything in theory, some examples will come in handy. They will help you better understand the information, and based on them, you can quickly create customized solutions for your needs.

Here are some user stories examples:

• For me, as a buyer, it is convenient to sort the online store catalogue by the goods features in order to quickly find what I need;
• As an online banking client, I want to see accounts changes in real-time in order to track the balance after each transaction;
• As a reporting system user, I want to be able to set a date range for outputting data in order to get a report for the desired period;
• As a project manager, I want to see the task load cross-referenced by the time taken for each employee in order to more efficiently distribute tasks.

As can be seen from the examples above, each story must have an ending – that is, lead to a concrete result. In Agile, this is the work unit that must be completed in one sprint.

How to Write a Good User Story?

A user story can contain requirements for UI, UX, and performance, etc. That is, it refers to functional and non-functional requirements. Their aggregate is used to form the product backlog.

Here are some tips for writing good user stories that can help you in your work:

1. Think from the user’s point of view. To write a valuable and realistic user story, you need to get the most information about your future users. Otherwise, you risk building on beliefs and false ideas, rather than real empirical data;
2. Be brief and clear. Write the stories so that they are easy to understand, and avoid confusing and ambiguous formulations. Treat them like a normal conversation between two people.
3. Do not be afraid to split them. Big stories can be split into smaller ones to achieve an optimal level of detail.
4. Do not confuse them with tasks. A good story explains what a person needs, not how the developer should do it. Don’t confuse them with each other.
5. Do this together. If you write them alone, there’s a risk that what one person understands will be completely incomprehensible to another. This can confuse some team members.
6. Use the acceptance criteria. Describe conditions that must be fulfilled so that the story is considered complete. Availability of 3-5 user story acceptance criteria simplifies the quality control of the final story.

One of the most common problems encountered in creating user stories is to find the optimal number of details that are revealed in it.

If it is not detailed enough, the team, instead of concentrating on implementing the story during the sprint, spends time searching for the missing answers. Developers are confused, filling the problems with what they think they need to add.

If you decide to add too many details into a user story, this, of course, will require additional time. But no one wants to spend more time than is really necessary. The correct ratio of details can be found only by the trial and error method of experimenting in practice.

Let’s summarize

User history is, ideally, the smallest indivisible task that has value for the user. They are not detailed at the very beginning of the project, but are to be worked out in more detail when it’s directly needed to avoid breaking the deadline while developing.

They are well suited to determine the product capabilities, but do not relate to requirements documentation. If you want to create a prototype or layout for testing ideas fast, you probably can do without working on them.

The key benefits of user stories are that having written them you start doubting: “Why do we make our product?”, “Who will use what we do?”, “Is this feature really needed in the product?”. Honest answers to these questions will help you design the best product.