A beginners guide to User Stories

Today we are going to teach you how to write user stories. If you are a Product Owner writing user stories is probably something that takes a lot of your time. But how to write them to provide an excellent way to define your product with most clarity?

What are User Stories?

User stories are part of an agile approach that helps to get into the user’s shoes and talk about his needs. All agile user stories include a written sentence or two and, which should be a result of a series of talks and thoughts about the desired functionality.

Why write User Stories?

Stories provide useful context for the development team and their efforts. Therefore after reading a user story, the team knows what functionality they are building, why and what value it creates.

What is important:

• Stories keep the team focused on solving problems for real users.
• They provoke collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
• User stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal.
• Stories keep the team motivated for achieving measurable goals.
• They enable the creation of the product with user needs in the first place.

How to write User Stories?

Basic user story consist of 3 elements:

As a <type of user>, I want <some feature> so that <some reason>

Let’s break this down one step further:

As a <type of user> — this is the WHO. Who are we building this for? Who is the user?

I want <some feature> — this is the WHAT. What are we building? What is the intention?

so that <some reason> — this is they WHY. Why are we building it? What is the value for the customer?

Examples of User stories

One of the benefits of agile user stories is that they can be written at different levels of detail. We can write a user story to cover large amounts of functionality. These large user stories are generally known as epics. Here is an epic agile user story example from a mobile to-do list application:

• As a mobile user, I want to manage my tasks, to have a clear view of my to-do list.

You should start defining the product by defining epics, which allows you to sketch the functionalities without focusing on details. This is particularly helpful for describing new products and its general features. The epic above could be split into dozens or hundreds of smaller user stories, like:

• As a user, I want to add tasks, to create my to-do list
• As a user, I want to change task priority, to know on what task I should focus in the first place.
• As a user, I want to mark my task as done, to keep my to-do list actual

How to add details to the story?

Acceptance Criteria or Conditions of Satisfaction, provide a detailed scope of a user’s requirements. They allow you to describe the conditions that have to be fulfilled so that the story is complete. AC can include:

• The negative scenario of the functionality
• Functional and non-functional use cases
• Performance guidelines
• The intention of the feature
• End-to-user flow
• Impact on other features
• UX concerns

Example of Acceptance Criteria:

• If the user withdraws/reject the creation of the task, he is taken to the main screen
• Successful creation of the task is indicated by
• Every new task jumps on the top of the list
• Name of the task is visible on the task card
• Added due-date it should be visible on the task card
• Added reminder should be visible on the task card
• Added priority should be indicated as a tag on the task cards

End-to-user flow

1. A mobile user is logged into the application and sees the main screen
2. A user taps on the new task button
3. User fills task name
4. User can add a description, due date, priority, and reminder
5. User confirmes new task
6. The task is added to the list

How detailed should be the stories?

It depends on you. But you should keep in mind that your team should be able to accomplish the whole story within one iteration.

When to write user stories?

User stories are written throughout the agile project. Usually, the first story-writing session is held shortly after the start of the agile project. The Product Owner and the rest of the team participate in the goal of creating a preliminary product backlog, which will be expanded for most of the project duration. Most of these user stories will undoubtedly be epics, which will later be decomposed into smaller stories that fit into a single iteration. Additionally, new stories can be written and added to the product backlog at any time.

Hope this guide was helpful, let us know how do you write user stories? If you are a Product Owner you should also check this “How to give difficult feedback without it getting personal” guide.