How To Write Great User Stories?

We already know “What Are User Stories And Why You Should Be Writing Them”, so it’s time to actually learn how to write a good one.

User Story Formula

We can easily craft a short and simple formula that will represent the user’s mindflow:

Based on a role:

As a <role person> , I can <a goal> so that <why>

Based on a class of user:

As a <particular class of user> , I want to <be able to perform/do something> so that <I get some form of value or benefit>

Make no mistake. “Simple” is far away from “Easy”. The process itself requires solid behavioral insights and your absolute focus on the user’s expectations.

This formula will help you build very simple, yet effective User Stories for any kind of user.

Let’s give them an example for better understanding.

As a user, I want a camera icon in the chat write box to capture and send pictures so that I can click and share my pictures simultaneously with all my friends.

As an admin, I can add new gifts to the gift list so that the users have the updated list of gifts.

This way, you make it extremely clear and easy to understand for developers, what type of user is expecting what kind of outcome from a specific functionality or feature.

Good practices

How to make sure you write good User Stories?

Here are a few practices to follow:

• Think like the User!
• Engage the whole team when writing a User Story (just make sure it won’t end up with the endless discussion and the idea pollution).
• Start from Epics and break them into smaller User Stories.
• Identify User Stories with numbers or letters.
• Indicate how much time is needed for each Story.
• Indicate priority.
• Clarify User Stories from a technical point of view (do not include technical requirements in a story!).

Bad practices

Let’s flip the coin now. Ho to do not write user stories:

• Use Epics for Tasks, or break them into substories.
• Use the stories that were not approved.
• Divide low priority Epics into user stories – it may be a waste of time.
• Include technical requirements.

Acceptance Criteria

By definition, acceptance criteria are “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholders.”

In other words, when the user is getting some precondition and do some action then he expects a specific result. Acceptance criteria are all the results that should satisfy his expectations.

Let’s consider that you are chatting with a friend on your phone. You should be able to capture a picture and after clicking on a picture, you should be able to add a caption to the image before sending it.

But what If there is a problem with starting your phone camera during that? In this case, Acceptance Criteria will be an error message like ‘Camera could not be started’, or else.

What about technical requirements?

It’s all beautiful, but at the end of the day, the developer needs to have a piece of the clear technical information he can follow.

Again, don’t mix Technical Requirements with User Stories.

They should be used together, to complement each other, not to substitute each other.

User Story should deliver a meaningful context to the Technical Requirements so that the developer can clearly understand the functionality from the user’s point of view.

Here’s another example:

User Story:

As a team member I will have my “Kudos to spend” balance renewed every month, so I can give them to other users.

Technical Story:

In order to renew the “Kudos to spend” balance, the CRON on the Heroku must be configured to start each first day on a month. An endpoint for starting reset points feature must be created.

Summary

To sum it all up using User Stories bring many advantages to the development process, as it is a simple way of clarifying the product’s goals and functionality.

This can significantly improve the collaboration of different parties – users, product owners, developers – and bring a lot of useful insights from each one of them.

Being clear is extremely important in the development process, as it saves a lot of time and money.

Done well, they can help you avoid hours of additional communication and put all the resources into the execution.