How to Write a User Story (With Examples and Templates)
User stories are one of the most widely used tools in product management — and one of the most frequently misunderstood. Done well, they keep development teams focused on user value instead of technical implementation. Done poorly, they become glorified task lists that nobody reads.
This guide covers everything you need to write great user stories: the correct format, how to write good acceptance criteria, real examples across different product types, common mistakes to avoid, and a template you can use immediately.
What Is a User Story?
A user story is a short, plain-language description of a feature or functionality written from the perspective of the user who will benefit from it. User stories come from the Agile methodology and are the most common unit of work for product teams using Scrum or Kanban.
The standard format is:
As a [type of user], I want [some goal] so that [some reason].
Here’s an example:
As a first-time buyer, I want to save my payment details so that I don’t have to re-enter them every time I check out.
The three parts — who, what, and why — keep the team anchored to a real user need rather than a technical requirement. If you’re new to agile workflows in general, our guide on what is agile product management gives useful context for how user stories fit into the broader sprint and backlog process.
Why User Stories Matter
Before agile methodologies became standard, teams wrote product requirements documents (PRDs) that specified exactly what to build, down to the technical implementation. This worked when products changed slowly and requirements were stable. It falls apart in fast-moving product development. For a detailed look at what a PRD covers and when it’s appropriate, see our guide on what is a PRD and how to write one.
User stories flip the model. Instead of telling engineers what to build, they describe what the user needs to accomplish. The team — engineers, designers, and PMs together — figures out how to build it.
This shift has three practical benefits:
They encourage collaboration. A well-written user story is the start of a conversation, not the end of one. Teams discuss how to implement it together, which leads to better solutions.
They keep focus on value. Every user story asks “who benefits and why?” before asking “what should we build?” This keeps teams from building features for their own sake.
They’re easier to estimate. Small, specific user stories are much easier for engineering teams to size and schedule than large, vague requirements.
The User Story Format Explained
The Three Parts
As a [user type] This is your persona — the specific type of user who will benefit from this feature. Be specific. “As a user” tells you nothing. “As a freelancer who invoices clients monthly,” tells you everything you need to empathize with the need.
I want [goal or action] This describes what the user wants to do. Focus on the action or outcome they want to achieve — not the specific UI implementation. “I want to see a summary of my monthly spending” is better than “I want a pie chart on the dashboard.”
So that [benefit or reason] This is the most frequently skipped part — and the most important. The “so that” forces you to articulate the underlying reason behind the feature. It helps the team understand what success looks like and often unlocks better solutions.
User Story Examples
E-commerce
As a returning customer, I want to view my full order history so that I can quickly reorder products I’ve bought before.
As a shopper, I want to filter search results by size and color so that I only see products that are available in what I need.
As a guest user, I want to check out without creating an account so that I can complete my purchase quickly without committing to signing up.
SaaS / B2B
As a team admin, I want to set permission levels for each team member so that I can control who can view, edit, or publish content.
As a project manager, I want to assign tasks to specific team members with due dates so that everyone knows what they’re responsible for and when.
As a billing administrator, I want to download a PDF invoice for each month so that I can reconcile our company’s accounts.
Mobile App
As a commuter, I want to save my most-used routes so that I don’t have to search for directions every morning.
As a user who exercises regularly, I want to set weekly fitness goals so that I can track my progress toward a target.
As a new user, I want to complete a short setup flow when I first open the app so that the experience feels personalized from day one.
Platform / API
As a developer, I want to authenticate via OAuth 2.0 so that I can integrate the API without managing passwords.
As an enterprise customer, I want to export all of my account data in JSON format so that I can migrate to another platform if needed.
How to Write Acceptance Criteria
A user story by itself doesn’t tell engineers when they’re done. That’s what acceptance criteria are for.
Acceptance criteria are a set of conditions that must be true for the user story to be considered complete. They define the boundaries of the feature and prevent scope creep.
The most common format is Given / When / Then (also called Gherkin syntax):
- Given [some context or precondition]
- When [the user takes an action]
- Then [the expected outcome]
Acceptance Criteria Example
User Story: As a user, I want to reset my password so that I can regain access to my account if I forget it.
Acceptance Criteria:
- Given I am on the login page, when I click “Forgot password,” then I am taken to the password reset page.
- Given I enter a valid email address, when I submit the form, then I receive a password reset email within 2 minutes.
- Given I click the reset link in my email, when the link is less than 24 hours old, then I am taken to a page where I can set a new password.
- Given I click the reset link in my email, when the link is more than 24 hours old, then I see an error message telling me the link has expired with an option to request a new one.
- Given I enter a new password that meets the requirements, when I submit, then my password is updated and I am automatically logged in.
Tips for Writing Good Acceptance Criteria
Be specific. Vague criteria (“the page should load quickly”) can’t be tested. Specific criteria (“the page should load in under 2 seconds on a standard 4G connection”) can.
Write from the user’s perspective. Acceptance criteria should describe what the user experiences, not how the system implements it internally.
Cover edge cases. What happens when the input is invalid? What if the user is on a slow connection? What if the session has expired?
Aim for 3–8 criteria per story. Fewer than 3 and you’re likely missing edge cases. More than 8 and the story is probably too big and should be split.
User Story Template
Here’s a reusable template you can adapt:
Story Title: [Short descriptive name]
User Story: As a [specific user type], I want to [accomplish some goal], So that [I receive some benefit/value].
Background / Context: [Optional: any relevant context the team needs to understand the story]
Acceptance Criteria:
- Given [context], when [action], then [outcome].
- Given [context], when [action], then [outcome].
- Given [context], when [action], then [outcome].
Out of Scope: [What this story explicitly does NOT include — helps prevent scope creep]
Dependencies: [Any other stories, APIs, or systems this story depends on]
Priority: [High / Medium / Low] Story Points / Estimate: [Team estimates this in refinement]
What Makes a Good User Story: The INVEST Criteria
The INVEST model, originally developed by Bill Wake, is a useful checklist for evaluating the quality of a user story:
- Independent — can be developed and delivered without depending on other stories
- Negotiable — the details are open to discussion; the story isn’t a contract
- Valuable — delivers real value to the user or business (not just a technical task)
- Estimable — the team can roughly size it
- Small — small enough to complete in one sprint (usually 3–5 days of work)
- Testable — there are clear criteria for determining when it’s done
If a user story fails any of these, it usually needs to be rewritten or split.
User Stories vs Use Cases vs Tasks
These terms are often confused. Here’s how they differ:
User stories describe what a user wants to accomplish and why. They’re written in plain language for any audience. They’re the most common format in modern agile product teams.
Use cases are more formal, detailed specifications that describe all possible interactions between a user and the system. They were popular before agile methodologies became standard and are still used in enterprise and regulated industries.
Tasks are technical implementation steps — things like “set up the database schema” or “write the API endpoint.” They’re not user stories. Good user stories shouldn’t describe implementation at all.
Common Mistakes When Writing User Stories
Writing tasks, not stories “Build the settings page” is a task. It tells the team what to build, not who benefits or why. Rewrite it as: “As a user, I want to customize my notification preferences so that I only receive alerts that are relevant to me.”
Being too vague about the user “As a user,” could describe anyone. The more specific you are — “as a project manager at a company with 50+ employees” — the better the team understands who they’re designing for.
Skipping the ‘so that’ clause The why behind a feature often unlocks better solutions. If you skip it, you lose context and might end up building the right thing the wrong way.
Writing stories that are too large A story that covers an entire feature (“As a user, I want a complete checkout flow”) can’t be delivered in a sprint. Break it down into smaller, independently deliverable stories.
Mixing technical requirements into user stories “As a user, I want the system to use PostgreSQL so that queries run faster” is not a user story — it’s a technical requirement masquerading as one. Users don’t care about the database. Write: “As a user, I want search results to load in under 2 seconds so that I can find what I need quickly.”
Epics: When User Stories Get Too Big
An epic is a large body of work that can be broken down into smaller user stories. Epics are useful for planning and organizing work at a higher level before you’re ready to write detailed stories.
For example:
Epic: Checkout experience overhaul
User stories under this epic:
- As a guest user, I want to check out without creating an account…
- As a returning user, I want to use saved payment details…
- As a mobile user, I want to complete a purchase in under 3 taps…
- As a user in Europe, I want to pay via iDEAL…
Epics typically live on the roadmap. User stories live in the sprint backlog. Good backlog hygiene — knowing when to write detailed stories versus keeping things at the epic level — is one of the core skills covered in our guide on how to prioritize a product backlog.
Final Thoughts
User stories are deceptively simple. The format takes 30 seconds to learn. Writing great user stories — ones that are specific, outcome-focused, and genuinely useful for your team — takes practice.
The key habits to build: always name the specific user, always include the “so that,” always write acceptance criteria before the story goes into a sprint, and always ask whether the story is small enough to be completed in a few days.
When user stories are done well, they create shared understanding across the entire team — and that shared understanding is what makes great products possible.
References
- Cohn, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley, 2004.
- Agile Alliance. “User Stories.” agilealliance.org
- Atlassian. “User stories | Examples and Template.” atlassian.com
- Wake, Bill. “INVEST in Good Stories, and SMART Tasks.” XP123, 2003.
