User Story: How to Write Quality User Stories

Some applications, websites, and other IT products, like a magnet, attract and hold users firmly so that you don't want to leave them at all. Is it about the user interface? Thoughtful texts? Special programming magic? Maybe. But often, the explanation is simpler: the creators of the product have worked out every possible User Story well and, thanks to this, have predicted the client's desires. What are user stories, why are they needed and how to create user stories and use them — we answer questions in the article.

In this Article:

What are User Stories?

Working with the audience is one of the most important components of creating products because it is the users who will determine its success. Therefore, you need to understand how users will interact with your app or site. To better understand this, there is a User Story.

A user story, or User Story, is a description of product features in simple language, written from the user's point of view. It helps to understand how the application functionality will benefit the client, even at the stage of project analytics. User stories serve as a kind of context for developers: they understand what the end-user wants from the product and work more purposefully. These stories consist of several sentences and do not go into details: they capture the essence and focus on the main thing.

What is the User Story used for?

User stories help focus on the user's needs: how will they use the app? What does he expect from the product? How will he behave in a given situation? Thus, the answers to these questions will help product creators solve real customer problems. Here are a few main tasks for which you need to use User Stories:

1. Organize work 

When a project is broken down into parts related to user stories, each of them is a cohesive and understandable task. So developers can focus on each of them and get a measurable result. So, for example, we described user requirements using discrete User Stories to develop an online learning platform. This helped the client, with a limited budget, to flexibly manage development priorities by adding or excluding User Story.

Strengthen your company

A BA analyst role in the Agile team

The business analyst role in Agile is essential, as this person makes positive changes by understanding the business problems, recommending the solution, and increasing the ROI for projects.

Tell me more

2. Keep the focus on the user

Of course, product development includes dozens of complex tasks related to technical, financial, and other issues. However, user stories are a constant reminder to the team of those for whom this product is being created and direct their work in the right direction. Who is the user of your application, and how can you be useful to him? The answers to these questions will help you create a quality user story.

3. Rally the team

Despite the fact that everyone has their own tasks (design, testing, development), everyone understands the ultimate end goal and sees themselves as part of the whole. Only by working together can the user achieve the desired result, and user stories provide a clear understanding of this aspect of the work.

4. Find new solutions

The development team tries to come up with the most pleasant and interesting way to solve the user's problem. Often this leads to the emergence of new interesting ideas and their implementation. The result is a useful and unique product.

User Story Structure

Your user story will be unique, so you can create your own unique way of telling it. However, there are standard elements of creating a user story that will help you best ''read the mind'' of the user and understand their way of thinking. These elements include:

Once you have understood the basic end-user behavior patterns, you need to describe their actions in more detail. How will they order food on your app? What will they look for on the university website? By what criteria will they search for a doctor? Start with what you have and try to represent user behavior as accurately as possible.

With User Stories, you can start building your product more thoughtfully. The formulation of functional requirements will become easier, you will already see the result, and it will be easier to achieve it with this understanding.

INVEST criteria for writing User Stories

Sometimes it can be difficult to figure out which designed user stories are right for you and how to write a user story. To resolve this issue, you can use the INVEST criteria. This abbreviation consists of the most important components of a successful user story. Let's take a closer look at these criteria.

I - Independent. A particular story should not be influenced by other stories — or minimally. This will allow you to work through each one without having to wait for any other story to finish.

N - Negotiable. In other words, the user story needs to be discussed in detail and come up with an optimal solution. At the same time, the story should be capacious and concise, reflecting its main idea. Agile User Stories, or flexible user stories, is a good opportunity to adapt to any external changes. We also have a practice in Geniusee, where several approaches to its management can be applied within the framework of one project, which makes the work personalized and of high quality.

V - Valuable. This is a fairly simple and understandable point: the user story should be valuable, and the described functionality should benefit the business.

E - Estimable. You should be able to evaluate this story: calculate the resources needed to work on it, determine the time frame for implementation, and set criteria for success.

S - Small.  User stories should not describe the entire functionality of the product but focus on a specific narrow task. This will help you implement the story in a short iteration and move quickly on the project.

T - Testable. To write user stories, you should be able to test them — understand how much users need them, what the shortcomings are, and how stories could be changed. This will help you get feedback from the audience and bring the product to perfection.

Common Mistakes in User Stories

Story for the user

Example: "As a user, I want to manage the display of special offers in order to remove outdated and outdated ones."

What's wrong with this story? All the important parts seem to be in place, but looking closer, we don't know who we're designing this story for. Perhaps our user is a system administrator who needs to pre-moderate the display of special offers from advertisers? Or perhaps he's an advertiser who needs to manage how promotions appear on the list?

These users will have completely different expectations from the system. The mistake of this story is the inattention to the user's role in it.

Get to know your user

Customer Discovery: a complete guide

Show customer and user care, so they get back to you. Yet, first, find out who is your real user

Show me the full guide

Story for the developer

Example: "As a developer, I want to migrate to the X software library so that I have the latest version of the X library."

Often such stories are written to explain what needs to be done as part of technical debt and refactoring, and here the team is already the direct customer. However, it won't be easy to convince the business of the need for such a story because, in words, it does not create any value for the user. How to deal with it if the task is really necessary and useful?

You need to look at what library X does for the end-user of the product. For example, it allows you to create special offers faster and removes the delay after they are created. Then the story might look like this:

"As an advertiser, I want the system to have no delays after creating specials, so that I can work faster with a large volume of specials."

Rewrite it from a user point of view: "As an advertiser, I want the system to allow me to create folders so I can work faster with large ad lists."

The technical notes for this story might look like this:

''Refactor the mechanism for adding special offers.''

"Update the library version responsible for the animation of adding special offers."

At the same time, it is much easier to write acceptance criteria for such a story:

"The user should not see delays after creating a special offer at normal internet speeds."

No business value for the user

Example: "As a system administrator, I want to be able to sort specials."

It seems that everything is in place, except for the value for the user. Why does an administrator sort special offers? Without understanding the purpose of sorting, it is impossible to formulate further requirements for it, and the story loses its meaning.

One more before summing it up

7 Tips On How To Manage An IT Project Successfully

Do you know what is the secret of delivering a successful product on time and withing budget? Here are some advices based on our real experience

Let me see

Conclusion

If you write high-quality user stories, you can predict user behavior and provide them with a product that fully meets their needs. Write to us at info@geniusee.com with your project idea — we will help you create high-quality user stories and a reliable product based on them.