How to Write User Stories with Examples (2026 Guide)
A practical guide to writing user stories that engineers can build and QA can test. Includes real examples for authentication, e-commerce, dashboards, and notifications.
TL;DR
Good user stories follow the “As a [user], I want to [action] so that [benefit]” format, include 3-5 acceptance criteria, and pass the INVEST checklist. This guide provides real examples across feature types, shows common anti-patterns, and explains how to write stories that are small enough to build in a sprint and specific enough to test.
The User Story Format
Every user story follows the same structure: “As a [type of user], I want to [perform an action] so that [I get a benefit].” The three parts matter equally. The user type identifies who you are building for. The action describes what they want to do. The benefit explains why it matters. Without the “so that” clause, the story lacks purpose and engineers cannot make trade-off decisions.
User Story Examples by Feature Type
Authentication
“As a returning user, I want to sign in with Google so that I do not have to remember a separate password.”
Acceptance Criteria:
- Given I am on the login page, when I click “Sign in with Google,” then I am redirected to Google's OAuth consent screen.
- Given I authorize the app, when Google redirects back, then I am signed in and redirected to my dashboard.
- Given I have never signed up before, when I sign in with Google for the first time, then a new account is created with my Google profile data.
- Given Google auth fails, when the error callback fires, then I see an error message and can retry.
E-Commerce
“As a shopper, I want to filter products by price range so that I can find items within my budget.”
Acceptance Criteria:
- Given I am on the product listing page, when I set a minimum and maximum price, then only products within that range are displayed.
- Given I have set a price filter, when I clear the filter, then all products are displayed again.
- Given I set a price filter, when no products match, then I see a “No products found” message with a suggestion to widen the range.
Dashboard
“As a team lead, I want to see my team's sprint progress on a dashboard so that I can identify blocked items before standup.”
Acceptance Criteria:
- Given I open the dashboard, when the page loads, then I see a summary of the current sprint: total items, completed, in progress, and blocked.
- Given there are blocked items, when I view the dashboard, then blocked items are highlighted with the blocker reason visible.
- Given I click on a sprint item, when the detail panel opens, then I can see the full ticket description and recent activity.
Notifications
“As a user, I want to receive an email notification when someone comments on my ticket so that I can respond without checking the app constantly.”
Acceptance Criteria:
- Given someone adds a comment to my ticket, when the comment is saved, then I receive an email within 5 minutes.
- Given I have email notifications disabled in settings, when someone comments, then no email is sent.
- Given I receive the email, when I click “View Comment,” then I am taken directly to the comment in the app.
Common Anti-Patterns
- Too vague:“As a user, I want a better experience.” This is not actionable. What specific action? What specific improvement?
- Too technical:“As a developer, I want to refactor the auth module to use JWT.” This is a task, not a user story. User stories describe user needs, not implementation decisions.
- Too large:“As a user, I want to manage my account.” This is an epic containing 10+ stories. Break it into specific actions: change password, update email, delete account, etc.
- Missing the benefit:“As a user, I want to see a loading spinner.” Why? The benefit matters: “...so that I know the page is loading and do not click away.”
How Vantage Makes This Better
Vantage generates user stories directly from your PRD requirements. Each generated story includes the “As a / I want to / So that” format, acceptance criteria, and proper scoping. Stories are dependency-aware, so they are ordered correctly for sprint planning.
Because stories are generated from structured requirements, every story traces back to the specific PRD section that justifies it. When the PRD changes, affected stories are flagged for review automatically.