May 14, 2019
by Alexei Falco

How to Write User Stories for Better Project Management

Behind even the simplest app lies complex functionality. Both the app user and the admin perform dozens of actions within the app and every action should bring the expected result.

Such a user-centric approach is critical during mobile application development as it ensures customer satisfaction and high ROI in the future. But what exactly are User Stories, what are their benefits and how do you write a good one?

We’ll see each step in detail and will make sure you don’t miss a thing — because, in the end, you will be able to communicate with the development team in a more efficient manner and will learn an extremely actionable approach towards development. And because User Stories are understandable for both the developers and non-technical people, you can be 100% sure you and your team will be on the same page at every step of the project and it will be easier for you to monitor the results.

User Story 101: a guide to user-centricity

In simple words, a User Story is a short and understandable description of an app’s functionality. It contains three basic elements:

  1. The user (who?)
  2. The action (what does the user do?)
  3. The value (what benefit does this action bring?)

It describes a piece of work that can be done within one sprint. An example of a User Story would be:

As an app user, I can upload and edit my profile images so other users can recognize my profile by the profile image.

Now let’s break it down.

The user: the app user

The action: uploading photos from the phone to the app

The value: presenting oneself in an attractive manner because the user can choose from the best photos in the gallery.

As you see, nothing technical here. This User Story is clear and understandable for both the Product Owner and the development team. But the use of Stories allows Product Owners to better communicate their ideas and thoughts to the team, help the team better understand the product, and encourages creativity as Stories themselves do not specify how the action will be performed.

As well, because User Stories approach each action step-by-step, they are often called scrum User Stories due to their iterative nature.

Bill Wake came up with 6 attributes for the good User Story, known as INVEST:

Independent: no dependencies between Stories to avoid confusion.

Negotiable: Stories should not contain strict requirements for functionality and should allow room for creativity and discussion.

Valuable: Stories should bring value to the end users and they can also be prioritized in accordance with this value.

Estimatable: any Story should be easily estimated to ensure hassle-free development process.

Small: do not make it too complex and adjust the Story size to team expertise and available tools.

Testable: Story should be tested and be able to pass the test.

Now that we are clear with the User Stories, let’s see one more concept before moving to the Stories benefits and writing guide.

Epic is a body of work that unites related Stories together. Here is the difference between the Epic and the Story:

  • Epic: managing placed orders
  • Story: the end user wants to see the order details
  • Story: the admin sends notifications to the customer about the order status.

The benefits of creating User Stories

We have talked a bit about the benefits the User Stories bring to both the Product Owner and the development team. Let’s see them in more detail.

Better communication

Communication is often a pain point for the client and the development team.

The team demands a clear and informative description while the client may not always be aware of the professional jargon or simply has difficulties with sharing his vision. As a result, time is getting lost and the outcome may not match the expectations.

User Stories, in turn, ensure the immediate feedback, let both sides express their vision, and set a direction for idea implementation.

Easier planning

We already said that Stories should be estimable and easy to implement within a sprint.

Such fragmentation of work contributes to better work planning, decreases risk, and contributes to task prioritizing. As a result, the team meets the deadlines and the work processes movies in a steady manner.

Agile development

Agile development is an awesome way of getting things done step by step. This ensures maximum attention to each project stage and lets the team identify and eliminate any issues on the go.

When writing an agile User Story, you don’t need to have them all listed down at the very beginning. Start with a few and then gradually write more. Such an approach enables flexible development and lets the developers immediately implement any changes.

How to write a good User Story

Now that we are clear on what User Story is and why it matters, it’s time to find out how to write one!


Here are a few templates that you can use to get started:

  • As a [user] I want to [action] to [value]

Example: As a user, I want to add products to the wishlist so I can buy them later.

  • [User] does [action] to [value]

Example: Admin blocks inappropriate photos to provide a better experience for other users.

Steps to writing a great User Story

Having a template is not enough — you have to understand the basic steps of writing User Stories in order to make them truly helpful and valuable.

Define the users and their needs

Because you are writing User Stories you need to know your users and their needs, otherwise, you will not be able to offer them any value.

Keep in mind that “users” include both external (end users) and internal users (admins). To make it easier, create a buyer persona and outline a detailed portrait of each and the possible needs these people may have.

The biggest point here is to be sure about the value that your app and every action will bring to the users. For that, conduct studies, ask people and do not rely on the guesswork without any solid proofs.

List the possible actions

Once you have a portrait of the user and know about his needs, time to list down the actions that the user will most probably want to take to reach the goal/gain value.

Remember: each Story should have one action (otherwise, it’s an Epic). As well, do not rush to list down all the possible Stories at once. Start with the most critical one and gradually build up the app’s functionality.

Brainstorm on the best possible implementation

The beauty of User Stories lies in the fact that they leave plenty of room for creativity and let both the client and the team come up with the best possible way to implement the idea.

So once you have the users and the actions ready, arrange a meeting and discuss the ways of making these ideas come to life.

But how do User Stories impact my KPIs?

Because User Stories are built around the value, they mostly affect customer satisfaction. This, in turn, leads to increased engagement, the rise of conversions, decreased retention rate, and more.

If we get back to the example of a user adding an item to the wishlist, it will impact the KPI in the following way: because the user can save the item for later, it increases the chances of him coming back and buying from you instead of leaving the store for good. As well, wishlists retain the customers and encourage them to visit the store again and again instead of making a single purchase and forgetting about your existence.

Wrapping up

Even though there is a lot to think about, writing User Stories is actually easier than it sounds. But to get the most of it, we recommend finding a reliable software development company that works by Agile methodology and is open for transparent communication. In this case, you can rest assured about the quality of your project and the shared management over the development process.

At Celadon, for example, we always write User Stories at the beginning of the project and then discuss them with the client in case he did not write the Stories himself. This way, we work together as a team and always ensure we share the same vision.

Drop Us A Messageand we will get back to you in the next 12 hours