How to write great user stories
User stories are the foundation of any good product. They keep teams aligned around what users actually need. This guide covers the format, the rules, and the most common mistakes to avoid.
What is a user story?
A user story is a short, simple description of a feature told from the perspective of the person who needs it. It answers three questions: who needs it, what they want, and why they want it.
The standard format is:
As a [specific user role],
I want to [specific action],
So that [concrete benefit].
Why user stories matter
User stories shift the focus from features to outcomes. Instead of saying "build a login page," you say "enable a returning customer to access their account securely." That small shift changes how your team thinks about the problem.
Good user stories also make it easier to estimate effort, prioritize work, and define when something is actually done.
The three parts explained
As a [role]
Be specific. "User" tells you nothing. "Returning customer," "workspace admin," or "first-time visitor" gives context that shapes the solution.
As a user, I want to reset my password...
As a registered customer who forgot their password, I want to reset it via email...
I want to [action]
Describe one action, not three. If you find yourself writing "and," you probably have two stories. Keep it atomic.
So that [benefit]
This is the most important part and the most often skipped. The benefit explains the "why" and helps the team make better trade-offs during implementation. If you can't write the benefit, the story may not be worth building.
Acceptance criteria
Acceptance criteria define when a user story is done. The most reliable format is Given / When / Then:
Given [initial context or state],
When [the action is performed],
Then [the expected result].
Write 3 to 5 criteria per story. Cover the happy path, edge cases, and at least one error state.
A complete example
As a workspace admin,
I want to invite team members by email,
So that my team can collaborate on shared projects without needing individual account setup.
Acceptance criteria:
Given I am on the workspace settings page, When I enter a valid email and click Invite, Then an invitation is sent to that address.
Given I enter an email already in the workspace, When I click Invite, Then I see an error message indicating they are already a member.
Given the invitee clicks the link in their email, When they accept, Then they are added to the workspace with the default role.
Common mistakes to avoid
- Using "the system" as the role. Systems don't have goals. Users do.
- Writing technical requirements. "The API should return a 200 status" is not a user story.
- Skipping the benefit. "So that I can do it" is not a benefit.
- One giant story that covers an entire feature. Break it down until each story fits in a single sprint.
- No acceptance criteria. Without them, "done" is subjective and leads to rework.
How many stories do you need?
For a MVP, aim for 5 to 8 "Must" stories that cover the core user journey end to end. Everything else goes in a backlog and can wait.
Generate your user stories in seconds
Describe your feature and let the AI format it for you. Free, no sign-up required.
Try UserStoryGen