What is a user story? How to write one, with examples

The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.

Written by Phan Lam Duy Khoi

A good user story names a specific user, a real problem they have, and a slice of value small enough for the team to finish within a sprint. The “As a [who], I want [what], so that [why]” template only records it; what matters is the conversation and how the team will confirm it is done.

A user story sent back

This is an illustrative situation. You have just become the PO for the app of an online plant shop called Mầm Xanh (a fictional name). Sprint planning is coming up, so you quickly add one line to the backlog: “As a user, I want to manage orders, so that tracking is easier.”

In the meeting, a developer asks: “Is the user a customer or shop staff? Does manage mean view, edit or cancel? Do we need last year's orders?” The designer asks whether customers use phones or laptops. QA asks how anyone will know it is done. You can answer about half. For the rest you say “let me check”. The story slips to the next sprint.

Your story followed the template. It had all three parts: “As a…, I want…, so that…”. The template was not the problem. The sentence simply did not say who really needs this, where they struggle, and which part the team is building this time.

What is a user story, and why is the template not enough?

A user story is a short description of something a user needs to be able to do and why, written from that user's point of view. The backlog is the ordered list of work the team might do. A sprint is a short, fixed working cycle that ends with a usable piece of the product.

A widely used template is: As a [who], I want [to do what], so that [what I get]. You can learn it in five minutes. The hard part is in three places the template does not solve for you.

A real user. “User” or “customer” is far too broad. First-time buyers, repeat buyers and support staff have very different needs.
A real problem. The “so that” part is often filler, such as “so that it is easier” or “for a better experience”. A line like that does not help anyone choose between two approaches.
A small enough slice. “Manage orders” hides a dozen pieces of work. Put them in one story and the team can neither estimate it nor finish it in a sprint.

New POs often treat story writing as a writing task. Most of the effort actually goes into understanding the problem before you write, and into the conversation with the team afterwards. The words on the card are only the record.

If what you received was a message like “can you add this feature for me”, clarify it before you write any story. The article on handling feature requests covers that step in more detail.

How a new Product Owner handles feature requests

How to write a user story, step by step

One practical approach is to go through four steps in order. Do not open your work tracker at step 1. Draft on paper or in a separate file, and only add the story to the backlog at step 4.

Four steps to write a user story For new POs, step 3 usually takes the longest.

Pick the user: A specific group in a specific situation
State the problem: How they cope today, what would change
Cut a thin slice: One usable piece, done within a sprint
Agree on confirmation: Talk with the team, record what done means

If at step 4 the team still has questions nobody can answer, go back to step 2.

Step 1, pick the user. Replace “user” with a group you can name, plus their situation. For example, “a customer who has ordered and is waiting for delivery” rather than “customer”. If you cannot say who they are, you may not have talked to them or looked at any data about them yet.

Step 2, state the problem. Write one sentence about what they do today and why it is hard. For example: “Customers do not know where their order is, so they message the shop's page, and staff open each order to reply.” This sentence drives the “so that” part. If your “so that” just restates the “I want” in other words, you do not have a real problem yet.

Step 3, cut a thin slice. Ask: what is the smallest piece the user would already find useful? A good story is a vertical slice. It goes through enough interface, logic and data for the user to complete one task, however small. The next sections cover how to split a story that is too big.

Step 4, agree on confirmation. Take the draft to the developer, designer and QA. The point is for them to ask questions, not to sign off. After the conversation, write down the conditions that tell you the story is done. Those are the acceptance criteria.

What are the 3 C's: card, conversation, confirmation

Ron Jeffries described a story as three parts, often called the 3 C's. The main idea: the text on the card is only one third of the story.

The three parts of a user story Without the conversation, a story card is just a request written down again.

Card: A few lines, enough to recognise the story. The card reminds everyone this needs discussing; it does not hold every detail.
Conversation: The PO, developers, designer and QA discuss the story, mostly out loud, sometimes with examples or sketches. The real detail lives here.
Confirmation: Conditions agreed before the work starts, so at the end of the sprint the whole team can check whether the story is done.

For a new PO, the 3 C's remove one source of pressure: you do not need a perfect story before the meeting. You need a card clear enough to start the conversation, and a confirmation once the conversation is over.

Confirmation deserves its own article: how to write acceptance criteria that QA can test and developers do not have to guess at. This article only covers what you need here.

How to write testable acceptance criteria

What is INVEST? A quick check for any story

INVEST is a checklist for story quality, introduced by Bill Wake. Each letter is one criterion. You do not need a perfect score on all six, but a story that fails several should be rewritten or split.

The six INVEST criteria and the question to ask yourself
Criterion	Question to ask	Sign it is not there yet
I: Independent	Can this be built without waiting for another story?	“Do this after stories A, B and C”
N: Negotiable	Can the team still discuss how to build it, or is everything fixed?	Every button and colour is specified, with no room to discuss
V: Valuable	What does the user or the business get when it is done?	It is only a technical layer, such as “create the orders table”
E: Estimable	Does the team know enough to estimate the effort?	A developer says “no idea, we'd have to look”
S: Small	Can it be finished and tested within one sprint?	One story fills most of the sprint, or rolls into the next
T: Testable	Is there a way to know for sure it is done?	Nobody can say how to know the story is done

The two criteria new POs easily miss are V and S. A story with no value usually comes from splitting work by technical layer. A story that is too big usually comes from naming it after an area of the product, such as “order management” or “profile page”.

How do you split a story that is too big?

A story that is too big is often called an epic. An epic is not wrong; it is just not ready to build. Mike Cohn suggests several ways to split stories, known as SPIDR. Here are the four that are easiest for beginners.

Four ways to split a story that is too big Each smaller story must still give the user something useful.

By path: Each way the user reaches the goal is a story. For example, view the order in the app first, get a text notification later.
By data: Start with part of the data. For example, only orders from the last thirty days, with older orders in a later story.
By rule: Relax a complex rule for now and add it back later. For example, allow cancelling before packing, without automatic refunds yet.
By interface: Build a simple interface first and the full one later. For example, a plain text list first, an illustrated timeline later.

There is one more option: split off the research first. If the team does not know whether the delivery partner reports order status in real time, a short investigation lets the next story be estimated.

One kind of split to avoid is by technical layer: “story 1 builds the database, story 2 the API, story 3 the screen”. After story 1 or 2, the user has received nothing. That breakdown belongs to the engineers, as tasks inside a single story.

Before and after: the “manage orders” story

Back to the Mầm Xanh shop in our illustrative situation. After talking to customer support, you learn that most messages on the shop's page are customers asking where their order is. Staff open each order in the admin system to reply. That is a real problem: real people face it, and someone is spending effort on it.

The same story before and after clarifying (illustrative example)
Part	Before	After
As a	User	Customer who has ordered and is waiting for delivery
I want	To manage orders	To see which stage my latest order is at without messaging the shop
So that	Tracking is easier	I know when someone needs to be home to receive the plants
In scope this time	Not stated	Four stages: confirmed, packing, out for delivery, delivered
Not this time	Not stated	Order history, cancelling, text notifications
How we confirm	None	Written as acceptance criteria after the team conversation

In full, the new story reads: “As a customer who has ordered and is waiting for delivery, I want to see which stage my latest order is at without messaging the shop, so that I know when someone needs to be home to receive the plants.”

The parts you cut are not lost. They become the next stories in the backlog, each with its own user and reason:

As a customer waiting for delivery, I want a text when my order is handed to the courier, so that I do not have to open the app to check.
As a repeat customer, I want to see my past orders, so that I can reorder the same plant.
As a customer who ordered by mistake, I want to cancel before the shop packs it, so that I do not have to message and wait for staff.

Notice that the third story may not be needed soon. If customers rarely order by mistake, it can sit at the bottom of the backlog. Splitting lets you prioritise each piece by its value instead of accepting or rejecting one big block.

User story templates you can use today

The first template is a frame for one story, including the context and scope that the “As a…, I want…, so that…” line cannot hold. The second is a quick checklist before a story goes into a sprint. Copy them and adapt to how your team works.

Frame for one user story

Short name: [verb + object, e.g. View latest order status]

As a [specific user group, in what situation],
I want [what they need to be able to do],
so that [what they get, or what will change].

Context: [how they cope today, who spends effort, why now]
In scope this time: [short list]
Not this time: [short list, name the follow-up story if any]
Acceptance criteria: [write after the team conversation]
Open questions: [who answers, by when]
Discussed with: [dev, design, QA, operations], on [date]

Check before a story enters a sprint

[ ] The user and situation are named, not just "user"
[ ] The "so that" says what will change, not a restatement of "I want"
[ ] When this story is done, the user can complete one whole task
[ ] It does not depend on another story being finished first
[ ] The team has estimated it; nobody is saying "no idea yet"
[ ] It can be finished and tested within one sprint
[ ] What is left out this time is written down
[ ] It has acceptance criteria that QA can read and know how to test

Common user story mistakes

Writing “As a user”. This one is very easy to fall into. If every story starts with “As a user”, the “who” part tells the team nothing.
Writing a solution instead of a need. “I want a green button in the top right” is a design decision. Write what the user needs to be able to do, so the designer and developers can propose something better.
A filler “so that”. “So that it is easier” helps nobody decide. If you cannot write a concrete reason, go back and ask the people who have the problem.
Splitting by technical layer. A story like “build the orders API” has no value of its own for the user. Let the engineers break it into tasks inside a story.
Treating the story as a contract. Writing at great length so nobody can ask anything works against the whole idea. Detail comes from the conversation and is recorded in the confirmation.
Writing stories for everything. Fixing a typo or upgrading a library does not need the “As a…, I want…” format. A plain task is enough.

Summary

The “As a [who], I want [what], so that [why]” template is the easy part. The hard part is a real user, a real problem and a thin enough slice.
Write in four steps: pick the user, state the problem, cut a thin slice, agree on confirmation with the team.
A story has three parts: a short card, a conversation with the team, and the conditions that confirm it is done.
Use INVEST as a quick check. A story that fails several criteria should be rewritten or split.
Split stories by path, data, rule or interface, not by technical layer.

I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.

Get new articles by email

Frequently asked questions