![User Story format diagram showing the standard template: As a [user type], I want [action] so that [benefit]. Three components explained: WHO (As a user - the persona or role), WHAT (I want action - the feature or action needed), WHY (so that benefit - the value or outcome). Example: As a returning customer, I want to view my order history so that I can track my purchases.](/resources/images/templates/user-stories-format.svg?dpl=dpl_7ArAcQLLhWVjHgVHfvyJx9itARyL)
User Story Format
The standard user story template follows the 'As a... I want... so that...' format to capture who needs the feature, what they need, and why.
What is a User Story?
A user story is a simple, concise description of a feature from the end user's perspective. Unlike traditional requirements that focus on system capabilities, user stories emphasize the value delivered to users. They serve as a placeholder for a conversation between the product team and developers.
User stories originated in Extreme Programming (XP) and have become a cornerstone of agile development. They help teams stay focused on user needs rather than getting lost in technical details. A well-written user story enables the team to understand whoneeds what and why.
This guide provides a comprehensive user story template along with the INVEST criteria, acceptance criteria best practices, and real examples of good and bad user stories.
User Story Format
The standard user story format follows this structure:
As a [type of user],
I want [some goal]
So that [some reason/benefit]
As a [user type]
Identify the specific user persona or role. Be specific: "returning customer" is better than "user".
I want [goal]
Describe the action or capability the user needs. Focus on what, not how.
So that [benefit]
Explain the value or outcome. This helps prioritize and validates the need.
INVEST Criteria for Good User Stories
The INVEST acronym helps teams evaluate whether a user story is well-written. Stories that meet all six criteria are easier to plan, develop, and deliver.
Independent
Stories should be self-contained and not depend on other stories
Example
Can be developed in any order without blocking other work
Tip
If stories are coupled, consider combining them or restructuring
Negotiable
Stories are not contracts; details can be discussed and refined
Example
Implementation details are determined during development
Tip
Leave room for the team to find the best solution
Valuable
Every story must deliver value to the user or business
Example
"As a user, I want to filter search results" delivers clear value
Tip
If you cannot articulate the value, reconsider the story
Estimable
The team must be able to estimate the size/effort
Example
If a story cannot be estimated, it needs more refinement
Tip
Break down large or unclear stories into smaller pieces
Small
Stories should be completable within a single sprint
Example
A story taking more than a few days should be split
Tip
Large stories (epics) should be broken into smaller stories
Testable
Stories must have clear acceptance criteria that can be verified
Example
"User can successfully log in" is testable
Tip
Write acceptance criteria using Given/When/Then format
Writing Acceptance Criteria
Acceptance criteria define when a user story is "done." They should be specific, testable, and written from the user's perspective. The most common format is Given/When/Then (Gherkin syntax).
Given/When/Then Format
Given
The initial context or precondition
When
The action or trigger event
Then
The expected outcome or result
Example: Password Reset
User Story: As a registered user, I want to reset my password so that I can regain access to my account if I forget my credentials.
Given I am on the login page
When I click "Forgot Password" and enter my email
Then I receive a password reset email within 5 minutes
Given I have a valid reset link
When I click the link and enter a new password
Then my password is updated and I can log in with it
Given I have an expired reset link (older than 24 hours)
When I click the link
Then I see an error message and can request a new link
Real-World User Story Examples
Learn from these detailed examples with full context, acceptance criteria in Given/When/Then format, and explanations of what makes them effective (or not):
Well-Written User Stories
Context: E-commerce platform experiencing cart abandonment due to lengthy checkout
"As a returning customer who has purchased before, I want to save multiple shipping addresses to my account so that I can select from saved addresses during checkout and complete my purchase in under 60 seconds."
Acceptance Criteria (Given/When/Then):
AC1: Given I am logged in, when I navigate to Account Settings, then I see an "Address Book" section
AC2: Given I am in my Address Book, when I click "Add New Address", then I can enter street, city, state, zip, and country with address validation
AC3: Given I have multiple saved addresses, when I am at checkout, then I see a dropdown with all saved addresses and can select one with a single click
AC4: Given I have saved addresses, when I set one as "default", then it auto-populates in checkout for future orders
AC5: Given I have a saved address, when I click "Edit" or "Delete", then I can modify or remove it with a confirmation prompt for deletion
Why this works: Specific user segment (returning customer), quantifiable goal (60 seconds), comprehensive Given/When/Then criteria that define clear boundaries
Context: B2B SaaS tool where team admins need to manage user access efficiently
"As a team administrator managing a team of 50+ users, I want to bulk invite new team members via CSV upload so that I can onboard entire departments without manually entering each email address."
Acceptance Criteria (Given/When/Then):
AC1: Given I am a team admin, when I navigate to Team Settings > Members, then I see a "Bulk Invite" button alongside the single invite option
AC2: Given I click "Bulk Invite", when I upload a CSV file, then the system validates the file format and shows a preview of users to be invited (email, name, role)
AC3: Given my CSV contains invalid emails or duplicates, when I preview the upload, then invalid rows are highlighted with specific error messages and I can fix or skip them
AC4: Given the preview is correct, when I click "Send Invitations", then all valid users receive invitation emails within 5 minutes
AC5: Given invitations are sent, when I view the pending invitations list, then I see all invited users with status (pending, accepted, expired) and can resend or revoke invitations
Why this works: Clear persona with context (admin of 50+ users), specific problem (manual entry pain), edge cases covered (validation, errors)
Context: Mobile banking app where users frequently check balances on the go
"As a mobile banking user who checks my balance multiple times daily, I want to see my account balance on the home screen widget so that I can check my balance without opening the app or entering my PIN."
Acceptance Criteria (Given/When/Then):
AC1: Given I have the app installed, when I add the widget to my home screen, then I can choose between "Balance Only" or "Balance + Recent Transactions" widget sizes
AC2: Given the widget is installed, when I glance at my home screen, then I see my primary account balance updated within the last 15 minutes
AC3: Given I have privacy concerns, when I configure the widget, then I can enable "Tap to Reveal" mode that shows **** until tapped
AC4: Given my session has expired, when the widget cannot fetch data, then it shows "Tap to refresh" instead of stale data
AC5: Given I tap the widget, when the app opens, then it navigates directly to the account summary screen (bypassing the home screen)
Why this works: User behavior context (checks multiple times daily), privacy consideration as edge case, clear technical constraints (15-minute refresh)
Common Mistakes (and How to Fix Them)
The Problem Story:
"As a user, I want a better homepage."
What's Wrong:
Too vague—"better" is subjective and unmeasurable. No specific user type, no clear goal, no way to know when it is done.
Better Version:
"As a first-time visitor from a marketing campaign, I want to see a hero section with a clear value proposition and a single CTA so that I understand what the product does and can sign up within 30 seconds of landing."
Key Improvements Made:
Specifies user type (first-time from marketing), measurable goal (30 seconds to action), clear deliverable (hero + CTA)
The Problem Story:
"Implement OAuth 2.0 authentication with JWT tokens and refresh token rotation."
What's Wrong:
This is a technical task, not a user story. It prescribes the solution (OAuth 2.0, JWT) rather than describing the user problem. Developers should choose the implementation.
Better Version:
"As a user who accesses the app from multiple devices, I want to stay logged in for 30 days on each device so that I do not have to re-enter my password every session while maintaining security if my device is lost."
Key Improvements Made:
Focuses on user need (persistent login), includes constraint (30 days), mentions the trade-off (security vs convenience)
The Problem Story:
"As a user, I want all the features of the competitor app."
What's Wrong:
Not independent (requires many stories), not estimable (scope is infinite), too large (epic disguised as story), lacks specific value (which features? why do users want them?).
Better Version:
"As a power user migrating from CompetitorX, I want to import my saved projects via CSV export so that I can continue my work without manually recreating 50+ projects."
Key Improvements Made:
Picks ONE specific feature, explains the user context (migrating), quantifies the pain (50+ projects to recreate)
Complete User Story Template
A comprehensive template that includes all the sections you need for well-documented user stories. Click the copy button to copy the full template to your clipboard.
User Story Template
Complete template with all sections
# User Story: [Short descriptive title] | Field | Value | |-------|-------| | **ID** | US-[number] | | **Epic** | [Parent epic name] | | **Priority** | [High/Medium/Low] | | **Story Points** | [Fibonacci estimate] | | **Sprint** | [Target sprint] | ## Story **As a** [specific user persona/role with context], **I want** [specific capability or action] **so that** [measurable benefit or outcome]. ## Context & Background [2-3 sentences explaining why this story matters, what problem it solves, or what user research/feedback led to this story] ## Acceptance Criteria ### AC1 - **Given** [precondition/context] - **When** [action taken by user] - **Then** [expected outcome with specific details] ### AC2 - **Given** [precondition/context] - **When** [action taken by user] - **Then** [expected outcome with specific details] ### AC3 - **Given** [precondition/context] - **When** [action taken by user] - **Then** [expected outcome with specific details] > Add more criteria as needed, typically 3-7 per story ## Out of Scope - [Explicitly list what this story does NOT include] - [Helps prevent scope creep and sets clear boundaries] ## Design Assets - **Figma:** [Link to mockups] - **User flow:** [Link to flow diagram] ## Technical Notes - [Any technical considerations the team should know] - [API dependencies, data migrations, etc.] ## Open Questions - [ ] [Question that needs answer before development] - [ ] [Question for stakeholder or design clarification] ## Definition of Done - [ ] Code complete and peer reviewed - [ ] Unit tests written and passing (>80% coverage) - [ ] Acceptance criteria verified by QA - [ ] Product owner has approved the implementation - [ ] Documentation updated (if applicable) - [ ] Deployed to staging environment - [ ] No critical bugs or regressions
User Story Best Practices
Do This
- +Be specific about the user type
- +Focus on user value, not features
- +Keep stories small (1-3 days of work)
- +Include testable acceptance criteria
- +Refine stories before sprint planning
Avoid This
- -Generic "As a user" without specificity
- -Technical jargon or implementation details
- -Epics disguised as user stories
- -Skipping the "so that" clause
- -Writing stories without team input
Frequently Asked Questions
What is a user story in agile?
A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. User stories follow a specific format: "As a [type of user], I want [some goal] so that [some reason]." They are used in agile development to capture requirements in a way that focuses on user value rather than technical specifications.
What is the difference between a user story and a task?
A user story describes a feature from the end user perspective and focuses on the value delivered, while a task is a specific piece of work needed to implement a user story. For example, a user story might be "As a user, I want to reset my password," while tasks might include "Design password reset email template," "Create reset password API endpoint," and "Build password reset form UI." User stories are typically estimated in story points, while tasks are estimated in hours.
What are acceptance criteria?
Acceptance criteria are specific conditions that a user story must satisfy to be considered complete. They define the boundaries of the story and help the team understand what "done" looks like. Good acceptance criteria are testable, clear, and written from the user perspective. For example, for a login feature: "Given valid credentials, when the user clicks login, then they are redirected to their dashboard within 2 seconds."
What does INVEST stand for in user stories?
INVEST is an acronym that helps teams write good user stories: Independent (can be developed in any order), Negotiable (details can be discussed), Valuable (delivers value to users), Estimable (team can estimate the effort), Small (can be completed in one sprint), and Testable (has clear acceptance criteria). Stories that meet these criteria are easier to plan, develop, and deliver.
How detailed should a user story be?
User stories should be detailed enough to understand the user need and acceptance criteria, but not so detailed that they prescribe the solution. The story itself should be one sentence, with 3-8 acceptance criteria. Additional context, mockups, or technical notes can be attached but should not replace the story format. Teams often refine stories in backlog grooming sessions, adding detail as the story gets closer to development.
Who writes user stories?
Product Managers typically write user stories, but they should be collaborative. The PM owns the "what" and "why" (user need and value), while the team contributes to acceptance criteria and identifies edge cases. During sprint planning or backlog refinement, the team discusses stories together to ensure shared understanding. Anyone can suggest user stories, but the PM prioritizes and refines them.
How do you estimate user stories?
User stories are typically estimated using story points rather than hours. Story points measure relative complexity, effort, and uncertainty. Teams often use the Fibonacci sequence (1, 2, 3, 5, 8, 13) for estimation. During planning poker, each team member estimates independently, then discusses differences. Over time, teams develop a shared understanding of what each point value means for their specific context.
What is the difference between user stories and use cases?
User stories are brief, informal descriptions focused on user value, while use cases are detailed, formal documents describing system interactions. User stories are conversation starters that fit on an index card; use cases can be multiple pages with preconditions, main flows, alternate flows, and postconditions. Agile teams prefer user stories for their simplicity, while use cases are common in more traditional or regulated environments.
About the Author
Aditi Chaturvedi
·Founder, Best PM JobsAditi is the founder of Best PM Jobs, helping product managers find their dream roles at top tech companies. With experience in product management and recruiting, she creates resources to help PMs level up their careers.