10 User Story Examples + Templates for Agile Teams
TL;DR: What is a User Story?
A user story is a short description of a feature from the end user's perspective, following this format: "As a [user type], I want [goal] so that [benefit]."
Quick Example: "As a returning customer, I want to save my payment method so that I can checkout faster."
This guide covers 10 real-world user story examples by industry, the INVEST framework for quality stories, acceptance criteria templates, and how to break epics into stories. Whether you're new to agile or refining your backlog management skills, you'll find practical templates you can use today.
It feels like yesterday when I first sat in front of my product backlog. I saw a lot of lines with cryptic titles, ticket numbers, and different colors. I was completely overwhelmed and didn't know what to do.
I've managed 12 different team backlogs over the course of 7 years as PM, as well as multiple backlogs in my job as a Product Coach. After many sprints and projects, I came to one conclusion:
"A product backlog is a communication tool to make sure everyone is on the same side and we're all pulling the strings in the right direction."
If you've felt overwhelmed by your backlog, I want to share how I started and what lessons I learned with user stories and epics that help me manage my backlog today.
10 User Story Examples by Industry
Before diving into theory, let's look at real user story examples you can adapt. Each includes acceptance criteria to show what "done" looks like.
E-Commerce User Story Examples (1-4)
| # | User Story | Acceptance Criteria |
|---|---|---|
| 1 | As a returning customer, I want to save my payment method so that I can checkout in one click. | Add up to 3 cards; Display last 4 digits only; Set/change default card; Delete saved cards; PCI-compliant storage |
| 2 | As a shopper, I want to add items to my wishlist so that I can compare options and buy when ready. | Heart icon on product pages; Wishlist accessible from profile; Remove items from wishlist; Move to cart button; Max 50 items; Persists across sessions |
| 3 | As a guest user, I want to checkout without creating an account so that I can buy quickly. | Email required for order confirmation; Apply coupons without login; Option to create account post-purchase; Order tracking via email link |
| 4 | As a customer, I want to filter products by size and color so that I can quickly find items that match my preferences. | Filters persist during session; Show count of matching items; Clear all filters button; Combine multiple filters; Mobile-friendly collapsible UI |
SaaS/Product User Story Examples (5-7)
| # | User Story | Acceptance Criteria |
|---|---|---|
| 5 | As a team admin, I want to invite members via email so that my team can collaborate. | Bulk invite up to 10 emails; Pending invites visible with status; Resend or cancel pending invites; Invites expire after 7 days; Role assignment during invite |
| 6 | As a user, I want to export my data as CSV so that I can analyze it in spreadsheet tools. | Include all custom fields; UTF-8 encoding; Filename includes export date; Max 10,000 rows per export; Progress indicator for large exports; Email notification when ready |
| 7 | As a new user, I want a guided onboarding tour so that I understand key features. | Tour is skippable; Progress saved if interrupted; Max 5 steps; Highlights core actions only; Option to restart tour from settings |
Mobile App User Story Examples (8-10)
| # | User Story | Acceptance Criteria |
|---|---|---|
| 8 | As a frequent traveler, I want offline mode so that I can access my itinerary without internet. | Auto-sync when online; Clear offline indicator in UI; Last updated timestamp visible; Storage limit warning at 80% capacity; Manual sync button available |
| 9 | As a mobile user, I want biometric login so that I can access my account securely and quickly. | Support Face ID and Touch ID; Fallback to PIN code; Option to disable biometric in settings; Re-authenticate after 24 hours of inactivity |
| 10 | As a fitness user, I want to track my daily steps so that I can monitor progress toward my fitness goals. | Sync with Apple Health / Google Fit; Daily and weekly view toggle; Configurable daily goal; Goal achievement celebration; Historical data viewable |
What is a User Story? Definition Deep-Dive
Let's start with the definition of a backlog:
"...the Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product..." (Source: Scrum.org)
A user story is an item in that backlog. It's a collection of requirements detailed enough for Software Engineers to implement. Stories focus on the WHO, WHAT, and WHY in a testable format.
"Writing is thinking. In order to write, you have to think and thinking requires you to go deep into the topic. And the deeper you go into it, the more clear things ideally become."
— David McCullough, Pulitzer Prize-winning historian
As Product Manager, you'll drive the backlog activities and its items, called product backlog items or PBIs. The goal is to make sure that everyone knows what the priorities are, and commits to building a great product.
User Story Format and Templates
Here are the templates I use daily to write effective user stories.
The Classic User Story Format
As a [user type], I want [goal] so that [benefit].Example: As a customer, I want to be able to CRUD my products on my desktop PC, so that I have all product information in one place.
Problem Statement Template
When you need more context before writing stories, start with a problem statement:
Our service was designed to achieve [goal].
We have observed that the product isn't meeting these goals,
which is causing [negative outcome] for our users.
How might we improve the service so that our customers are more successful
based on [measurable success criteria]?Hypothesis Framework
For features that need validation:
We believe that [action] for [persona]
will result in [outcome].
We will know this is true when [measurable signal].Example: We believe that adding a one-click checkout for returning customers will result in 15% higher conversion. We will know this is true when we see checkout completion rate increase from 68% to 78%.
The INVEST Framework for Quality User Stories
I follow the INVEST guidelines (defined by Bill Wake) when I write stories. Here's what each criterion means with good and bad examples:
| Criterion | Meaning | Good Example | Bad Example |
|---|---|---|---|
| Independent | Can be developed without depending on other stories | "Add wishlist button to product page" | "Add wishlist button after cart is implemented" |
| Negotiable | Details can be discussed with the team | "Show product recommendations" | "Show exactly 8 products in a 4x2 grid with 12px spacing" |
| Valuable | Delivers clear benefit to users or business | "Enable faster checkout to reduce cart abandonment" | "Refactor payment service code" |
| Estimable | Team can size the effort | "Add color filter to product search" | "Improve the search experience" |
| Small | Fits in one sprint (ideally) | "Send email notification on order shipped" | "Build entire notification system" |
| Testable | Has clear acceptance criteria | "Display last 4 digits of saved card" | "Make the checkout user-friendly" |
Note: You can't always apply all points to a story due to complexity or cross-team dependencies. That's fine, but we always aim for it.
Writing Acceptance Criteria That Work
Acceptance criteria define when a story is "done." Here's my philosophy:
"Write the non-obvious acceptance criteria. If it's visible in the design, don't write it. If it's behavioral or technical, capture it."
Given-When-Then Format
For complex scenarios, use this structure:
Given [context]
When [action]
Then [expected result]Example:
Given a logged-in user with items in cart
When they click "Apply Coupon" with a valid code
Then the discount is applied and the new total displaysBest Practices for Acceptance Criteria
- 2-5 criteria per story (not too many, not too few)
- Focus on behavior, not implementation details
- Include edge cases (what happens when invalid input?)
- Make them testable by QA
If you have more than 5 acceptance criteria, consider splitting the story into smaller pieces.
User Stories vs Epics: The Hierarchy
Understanding the hierarchy helps you organize your backlog effectively:
Initiative → Epic → User Story → Sub-taskAn epic is an umbrella that collects related user stories. I use epics to capture high-level goals, not detailed solutions.
Epic Example
Epic Title: "Enable customers to manage products via web dashboard"
Broken into User Stories:
- As a customer, I want to create a new product with name and price...
- As a customer, I want to edit my existing product details...
- As a customer, I want to delete products I no longer sell...
- As a customer, I want to view all my products in a list...
Learn more about visualizing your stories with user story mapping.
Epic Title Best Practices
Bad titles I wrote early in my career:
- "Create products"
- "Create products online"
How I write them today:
- "Ability to CRUD products via our web interface/dashboard"
- "Enable customers to manage products at www.domainname.com"
Spending 30-60 seconds more on the title definition will help you and your team not get lost in a jungle of badly defined epics.
User Story Types Beyond Features
Not everything in your backlog is a "user story." Here are the different types I use:
| Type | Purpose | Example |
|---|---|---|
| User Story | New user-facing functionality | "As a user, I want to..." |
| Tech Story | Technical improvement without direct user impact | "Optimize database queries for product search" |
| Task | Specific work item (1-2 days) | "Set up CI/CD pipeline for staging" |
| Spike | Time-boxed research | "Investigate payment gateway options (2 days max)" |
| Bug | Defect fix | "Fix: Checkout button unresponsive on Safari" |
Tasks and spikes don't need full INVEST rigor. Spikes should always have a time-box and documented outcome.
Measuring Success: KPIs for User Stories
"In God we trust, all others bring data." - W Edwards Deming
Always define how you'll measure success. I use two types of KPIs:
| Type | Definition | Example |
|---|---|---|
| Leading | Predicts future success (looking forward) | Unique users visiting product page, time on page |
| Lagging | Confirms past success (looking back) | Number of products created, conversion rate |
Real Example (Hot Wally Crypto Wallet):
- Target: 5% user staking adoption within 6 months
- Leading KPI: 75% of active users visit the new staking tab in first month
- Lagging KPI: Total staked value, number of staking users
Learn more in 7 Product KPIs that make all the difference.
Common User Story Mistakes to Avoid
After years of reviewing backlogs, these are the mistakes I see most often:
- Feature Fatigue - Cramming too many requirements into one story. If it can't be done in a sprint, break it down.
- Technical Jargon - Writing from developer perspective instead of user. Always start with "As a [user type]..."
- Vague Acceptance Criteria - "Works on mobile" instead of "Works on iOS 15+ Safari and Chrome."
- Missing the Why - Skipping the "so that [benefit]" clause. This is crucial for prioritization.
- Writing in Isolation - The best stories come from collaborative refinement with your team, not solo PM work.
Backlog Hygiene: The 3-Month Rule
Here's a practice that changed how I manage backlogs:
"Close all backlog tickets older than 3 months. If they were truly important, they'll resurface."
This practice:
- Keeps your backlog manageable
- Forces real prioritization decisions
- Prevents "backlog bankruptcy"
If people don't come back to you and complain that you closed the ticket, it wasn't important at all. For comprehensive backlog strategies, read my backlog management guide.
Tools for Writing User Stories
The tool matters less than the practice, but here are popular options:
| Tool | Best For | User Stories Feature |
|---|---|---|
| Jira | Scrum teams at scale | Native story type, epics, story points |
| Linear | Fast-moving teams | Clean interface, cycles, sub-issues |
| Notion | Flexible documentation | Template blocks, database views |
| Avion.io | Story mapping focus | Visual story maps with Jira sync |
| Monday.com | Non-technical teams | Simple templates, visual boards |
If you're using Jira, check out how to estimate tickets effectively.
FAQ: User Stories Questions Answered
What is a user story example?
A user story example is: "As a returning customer, I want to save my payment method so that I can checkout faster." It captures the user role, desired action, and expected benefit in one sentence.
What is the format of a user story?
The standard format is: "As a [user type], I want [goal] so that [benefit]." This three-part structure ensures you capture WHO needs the feature, WHAT they need, and WHY it matters.
What is the difference between a user story and an epic?
An epic is a large body of work containing multiple user stories. For example, the epic "Customer Checkout Experience" might include stories for payment methods, shipping options, and order confirmation.
How many acceptance criteria should a user story have?
Aim for 2-5 acceptance criteria per user story. More than 5 suggests the story should be split into smaller pieces.
Summary + Next Steps
Quick Reference Card:
- Format: As a [user], I want [goal] so that [benefit]
- Quality: Apply INVEST criteria
- Size: If more than 8 story points, break it down
- Criteria: 2-5 acceptance criteria per story
The agile motto to remember:
"Start finishing. Stop starting." - Chuck Durfee
I've been applying this way of writing epics and stories for more than 3 years now. The key is consistency and collaboration with your team.
Continue Learning:
- User Story Mapping - Visualize your product backlog
- Definition of Done and Ready - Quality gates for stories
- How to Estimate Tickets - Sizing stories effectively
- 12 Sprint Planning Mistakes - Avoid common pitfalls
Want to discuss your backlog? Connect with me on LinkedIn.