User story guide

How to write user stories and acceptance criteria

User stories are how PMs and BAs communicate features to dev teams. Written well, they keep everyone aligned on what to build and why.

What is a user story?

A user story is a short, plain-language description of a feature from the user’s perspective. It keeps the focus on who the feature serves and why — not on technical implementation.

The format

As a [type of user], I want [action], so that [benefit].

User story examples by role

The same format applies across roles — what changes is who the user is and what problem they’re solving.

PMProduct Manager

“As a new user, I want to complete onboarding in under 3 minutes, so that I can start using the product without feeling overwhelmed.”

“As a free user, I want to see a clear comparison of free vs Pro features, so that I can decide whether to upgrade.”

BABusiness Analyst

“As a finance manager, I want to export expense reports as CSV, so that I can import them into our accounting software.”

“As an admin, I want to assign roles to users, so that I can control what each person can access.”

Writing acceptance criteria

Acceptance criteria define when a story is “done.” Without them, “done” means something different to every person on the team. The most common format is Given / When / Then.

Example

Given

A user is on the signup page

When

They enter a valid email and password and click ‘Sign up’

Then

They should receive a confirmation email within 2 minutes

INVEST criteria for good user stories

Before adding a story to the backlog, run it through INVEST. If it fails more than one criterion, rewrite it before estimating.

Independent

Can be developed on its own, without depending on another story being done first.

Negotiable

Not a fixed contract. The story is a starting point for a conversation, not a specification carved in stone.

Valuable

Delivers real value to the user or the business. If you can't explain why it matters, it shouldn't be in the backlog.

Estimable

The team can estimate the effort involved. If they can't, the story needs more definition or needs to be split.

Small

Fits in one sprint. If a story takes 3+ weeks, it's an epic — break it into smaller deliverable chunks.

Testable

Has clear acceptance criteria that confirm when the story is done. Vague stories can't be verified.

Common mistakes

Most bad user stories fall into one of four patterns. Here’s how to spot and fix each one.

Writing from the system's perspective

Wrong

'The system shall validate the email field.'

Fix

Rewrite from the user's point of view. 'As a user, I want to be warned if I enter an invalid email, so that I can correct it before submitting.'

Vague acceptance criteria

Wrong

'It should work properly.' or 'The page should load fast.'

Fix

Acceptance criteria must be testable. Specify what 'fast' means: 'Page loads in under 2 seconds on a 4G connection.'

Giant stories that span multiple sprints

Wrong

'As a user, I want a full reporting dashboard with filters, exports, and drill-downs.'

Fix

Break it down. Start with: 'As a user, I want to see a summary of my last 30 days of activity.' Add filters and exports as separate stories.

Missing the 'so that' clause

Wrong

'As a user, I want to receive email notifications.'

Fix

The 'so that' explains the why — and the why is what drives prioritization. Add it: '...so that I don't miss updates when I'm not logged in.'

Practice exercise

Reading about user stories isn’t enough — you need to write them to get comfortable with the format.

Try this

Pick any app you use. Write 3 user stories for 3 different features. Add Given / When / Then acceptance criteria to each one. Then run each story through the INVEST checklist and rewrite any that fail.

Next steps

Practice writing user stories in the PM or BA track

Both tracks include hands-on exercises where you write user stories for real product scenarios and get structured feedback.

Explore PM and BA tracks