UX Collective

We believe designers are thinkers as much as they are makers. https://linktr.ee/uxc

Follow publication

How to write a good user story — a practical approach

Olga Bartczak
UX Collective
Published in
5 min readJun 9, 2020

Green message icon on the yellow background.
Photo by Volodymyr Hryshchenko on Unsplash

A well-written User Story facilitates effective work for developers, testers, business analysts, product owners, and everyone interested in the project. But writing a User Story that will satisfy all the parties is a difficult task. Or is it?

What is a User Story?

There are a lot of good stories on Medium that talk about what a User Story is, and what it is not. I don’t think I need to reinvent the wheel, so let’s just see my favorite definition of User Story:

A user story helps agile software development teams capture simplified, high-level descriptions of a user’s requirements written from that end user’s perspective. A user story is not a contextless feature, written is “dev” speak. → story here

The key here it the user’s perspective. Remember — the User Story is not a piece of text for developers written in developers’ language. It should be understandable for all stakeholders, including the business side, that is not necessarily fluent in technology terms.

You should keep the User Story short, but detailed. Depending on the specific case, sometimes it is not easy to keep it that short but try to be precise and concise. The User Story should always concern one functionality only, and if it is too big, maybe it should become an Epic instead. Check this story to understand the difference between Epic and User Story.

What kind of information should a User Story have?

I have seen the whole range of information presented in User Stories. Depending on the project and workstyle of your team, you may prefer to use some of the sections, skip others or add something unusual for the particular User Story.

I am going to share with you the common template I use for writing User Stories during my everyday work.

1. User Story

As an Admin, I want to be able to assign tasks to Users so that I can delegate the work more efficiently.

I start with a traditional sentence a User Story usually starts with — As a <type of user>, I want <some goal> so that <some reason>. I try to be as precise as I can, but at the same time, keep the essence of the User Story in this one sentence and not overcomplicate it.

Think about this part in this way: By reading this sentence only, the person that is not involved in the project should understand the concept of the User Story well.

2. Background

The next part for me is usually the background of the story. I try to explain in a few sentences, why we even want this story to be developed, what it would change, and what the potential risks and benefits of the story are.

Currently, the manager needs to assign each task by e-mail or personally. This takes a lot of time and makes the manager work inefficient. We would like to implement functionality in our system, which will allow managers to automate their work. There is a risk, that not all the managers would know how to use this functionality, so the interface must be very intuitive.

This information should be enough for the developers to have an insight into the business decisions behind this User Story, and for the business side, it can be treated as a summary of the discussions about this User Story.

3. Mockup

If the User Story involves changing something in the UI, and it usually does, it is crucial to have some mockups done. Whether you are working with a UI/UX designer or not, these mockups can be more or less refined. It is essential to communicate clearly about what and how should change on the user interface level.

4. SBE (Specification by example)

I have seen this part named in many different ways. But the key is simple — what do I need to click to get the result that this User Story requires.

Log in as an Admin. Go to the “Tasks” page. Click on a task. You should see a field called “Assignee” where you can put the User’s name.

5. Acceptance Criteria

The Acceptance Criteria — the essence of the User Story. For me, this is the most important part, and usually the longest, that’s why I like to keep it as the last one. In this section, you should list all the detailed requirements to make this User Story come true. This is a guideline list for developers when developing, for testers when testing, and for Product Owner when accepting the User Story. You want to be as explicit here as you can, whilst keeping the criteria structured.

I like to have the criteria written in a form of a numbered list, adding indentations where I need to be more detailed. Remember to specify all the scenarios that are connected to the functionality. Should the field be mandatory or not? What happens if the user that was once assigned to the task deletes their account? Should the users see each other’s task? Or only their own? There are a lot of edge cases to every User Story, and specifying them in advance helps to improve the development process.

Do I need all of these sections?

Of course not! It always depends on the particular User Story you are working on. Sometimes it is enough to write the User Story and the Acceptance Criteria. Sometimes you need to add a custom section because of the specification of the User Story. Maybe you need to show what connections this User Story has with other User Stories? It is up to you.

Keep in mind, that in the end, the User Story has to fulfill its purpose — describe the functionality in a detailed, understandable way. There are many ways to achieve that, so why not experiment?

The UX Collective donates US$1 for each article published in our platform. This story contributed to UX Para Minas Pretas (UX For Black Women), a Brazilian organization focused on promoting equity of Black women in the tech industry through initiatives of action, empowerment, and knowledge sharing. Silence against systemic racism is not an option. Build the design community you believe in.

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Written by Olga Bartczak

Business Analyst by day, Board Game Player by night.

Responses (1)

Write a response

Hello, I am a design student who is doing a product internship, and your article has greatly inspired me. Can I translate your article into Chinese and share it with my friends? I will attach the original author and the original link. Thank you!

--