DEV Community

Cover image for Why (and how to) write User Stories?
Raffaele Pizzari for Studio M - Song

Posted on • Edited on

Why (and how to) write User Stories?

(this article was originally posted on my blog)

Most of my posts are just personal notes I take to reflect on my daily work or to prepare for a meeting.

Sometimes I think they could be food for thought for someone else and as it happened today, here I am writing these lines.

I asked myself 3 simple questions:

  1. Why do we write User Stories?
  2. How should we write User Stories?
  3. What are acceptance criteria used for?

Just to give you some context, I’m talking about user stories as units of work in an agile framework.
I know there is an immense literature on this subject and I don’t want to reinvent the wheel but I took the time to think and respond with concise and clear answers.


Why do we write User Stories?

1. To focus on users

Stories focus on users and their needs and are aimed at solving real problems and to add real value to the project.

2. To encourage critical and creative conversations

Stories empower critical and creative discussions about the product in the development team and create conversations between the development team and the external stakeholders.

3. To deliver a product that the client really needs

With each passing story the development team enjoys a small challenges and a small win, driving momentum.

How should we write User Stories?

In order to describe a functionality from a user’s perspective, we use a simple structured template:

“As a User Persona, I want to …, so that …”

a) as a User Persona

Who is the user? Who are we building this for?

b) I want to

What is the User trying to achieve?
What does the User want/need to do?
I personally find very useful what Max Rehkopf [wrote here](User Stories | Examples and Template | Atlassian: <>

c) So that

What is the problem that needs a solution?


What are acceptance criteria used for?

To define the scope

It’s very important to set some boundaries from technical and design perspective.

To know when the story is done

When acceptance criteria are met, the story can be considered done.

Align expectations

The development team and the customer must have the same expectations about the outcome of the story.

To improve the planning

Well defined acceptance criteria could generate clear subtasks.



I would be delighted to know your opinion on user stories, how you would have answered the 3 questions, what tips and tricks you use in your work.

Image by StartupStockPhotos from Pixabay

Top comments (0)