This article gives you ready-to-copy user story templates, dozens of examples organized by domain, and the acceptance-criteria and splitting rules that turn a rough idea into something sprint-ready. You'll find the standard format, job story variants, Given/When/Then examples, and the splitting patterns that keep stories small enough to estimate. Every example comes with a one-line acceptance note so you can paste it straight into your backlog.
TL;DR:
- Well-written stories should be small enough to finish in a single sprint by splitting on workflow or data type.
- Acceptance criteria must be specific, using Given/When/Then clauses that are automatable and testable within minutes.
- Avoid vague, overly technical, or overly broad stories by focusing on clear user benefits and meaningful roles, not technical tasks or vague outcomes.
- Structuring stories with clear roles, motivations, and benefits ensures better prioritization and reduces refinement friction.
- Starting from a detailed, prioritized feature list and defined customer profiles leads to more precise, actionable backlog items.
Table of Contents
- The User Story Template and Its Common Variants
- What Makes a Good User Story: INVEST and the Three C's
- Writing Acceptance Criteria That Are Actually Testable
- Curated User Story Examples by Domain
- Splitting Epics and Deciding Story Size
- Common Anti-Patterns and Fast Fixes
- How Structured Planning Produces Sprint-Ready Stories
- A Note on Keeping Refinement Honest
- Try a Faster Path From Idea to Story Bank
- FAQ
- Sources
The User Story Template and Its Common Variants
The canonical format is "As a role], I want [capability] so that [benefit]." The role tells you who benefits, the capability states what they need, and the benefit explains why it matters. This structure holds up because it captures who, what, and why in one line, which helps stakeholders contribute backlog items quickly and lets product owners prioritize by value rather than by feature complexity, as laid out in the [three-part template.
Two variants come up often enough to be worth knowing.
- Job story: "When [situation], I want to [motivation], so I can [outcome]." This drops the role in favor of a trigger, which works well when the context matters more than the persona, such as "When my session times out, I want to resume my form, so I can avoid retyping my answers."
- Technical shorthand: a plain task line like "Add retry logic to the payment webhook handler" with no role at all. Infrastructure and maintenance work rarely has an end-user role, and forcing one just adds noise.
Use the standard template for anything a customer or internal user directly experiences. Use the job story version when a situational trigger drives the need more than a persona does, such as session expiration or a failed upload. Use technical shorthand for backend plumbing, migrations, or refactors where there's no meaningful "so that" from a user's point of view. Not every backlog item has to be a user story at all; a healthy backlog mixes stories, tasks, and bugs, and Scrum guidance on backlog composition is explicit that forcing everything into the story template creates friction instead of clarity.
What Makes a Good User Story: INVEST and the Three C's
Before a story enters a sprint, it should pass two quick filters: INVEST and the three C's. Both take under a minute once you know what to look for.
- Independent: can this ship without waiting on another story? If not, combine or reorder them.
- Negotiable: does it describe an outcome, not a locked implementation? If it reads like a spec, strip out the "how."
- Valuable: does it deliver something a user or the business actually cares about? If you can't name the beneficiary, cut it.
- Estimable: can the team size it without a research spike? If not, split off a spike first.
- Small: can it ship within a single sprint? If it spans multiple workflows, split it.
- Testable: can you write a pass or fail check for it? If you can't, the story isn't done being refined.
The three C's, Card, Conversation, and Confirmation, describe how a story moves from idea to shippable work. The card is the short-written version, just enough to remember what it's about. The conversation is where the team and stakeholders fill in the details that the card deliberately leaves out. The confirmation is the acceptance criteria: the concrete, testable conditions that prove the story is done. Treating acceptance criteria as the confirmation step, rather than as decoration added after the fact, is what keeps the first two C's honest.
Pro Tip: Read a story out loud in refinement. If anyone asks "but what happens if...", that's a missing acceptance criterion, not a reason to reject the story.
Writing Acceptance Criteria That Are Actually Testable
Acceptance criteria exist to answer one question: how do we know this story is done? Vague criteria like "the page should load fast" or "the form should work well" can't be tested, which means they can't satisfy the Definition of Done, no matter how the team interprets it. The Given/When/Then format, borrowed from Gherkin, forces specificity because each clause names a precondition, an action, and an expected result, as described in this Gherkin acceptance criteria guidance.
- Given a logged-in user on a product page, When they click "Save to Wishlist," Then the item is added and a confirmation message appears.
- Given a cart with an expired promo code, When the user proceeds to checkout, Then the discount is removed and a notice explains why.
- Given a report with no data for the selected date range, When the user opens the report, Then an empty state message displays instead of a blank chart.
- Given a mobile user with no network connection, When they open a previously loaded screen, Then cached content displays with an offline indicator.
One example given, when, and then clause can be validated by an automated check within minutes, according to Gherkin acceptance criteria guidance, because each clause names a specific trigger and a specific result rather than a general feeling. Reserve manual testing for genuinely subjective outcomes, like whether an error message reads clearly, and automate anything with a measurable threshold, like load time or element visibility. Keep the list short: three or four criteria per story is usually enough. A story with ten acceptance criteria is almost always two or three stories wearing one trench coat.
Curated User Story Examples by Domain
Here's a working bank of examples across five common domains, each paired with a short acceptance note describing what confirms it's done. Adapt the role and benefit to your own product, but keep the structure intact.
SaaS
- As a team admin, I want to invite teammates by email so that they can access our shared workspace. Acceptance: invited user receives an email with a working signup link tied to the correct workspace.
- As a free-tier user, I want to see my usage against my plan limit so that I know when to upgrade. Acceptance: usage bar updates in real time and links to the upgrade page at 80% usage.
- As an account owner, I want to export billing history as a CSV so that I can reconcile it with my accounting software. Acceptance: exported file includes date, amount, and invoice ID for the last 12 months.
- As a returning user, I want my session to persist across browser restarts so that I don't log in every time. Acceptance: session token remains valid for 14 days unless manually logged out.
E-commerce
- As a shopper, I want to filter products by price range so that I can narrow results to my budget. Acceptance: filter updates results without a full page reload and shows the active range.
- As a shopper, I want to save items to a wishlist so that I can find them later without rebrowsing. Acceptance: wishlist persists across sessions for logged-in users and syncs across devices.
- As a shopper, I want to see estimated delivery dates at checkout so that I know when to expect my order. Acceptance: date shown accounts for carrier, destination, and current processing time.
- As a returning customer, I want one-click reorder from my order history so that I can repurchase without rebuilding my cart. Acceptance: reorder populates the original cart contents, substituting out-of-stock items with a notice.
Internal tools
- As a support agent, I want to see a customer's last five tickets on their profile so that I have context before replying. Acceptance: ticket list loads with the profile page, no separate click required.
- As an operations manager, I want to export weekly task completion rates so that I can report them to leadership. Acceptance: export includes per-team breakdown and matches the dashboard numbers exactly.
- As a new employee, I want a guided checklist on my first login so that I know which systems to set up. Acceptance: checklist items persist as checked across sessions and disappear once all are complete.
Marketing
- As a marketer, I want to schedule a campaign email in advance so that it sends at the optimal time without manual triggering. Acceptance: scheduled email sends within one minute of the set time and logs the send event.
- As a marketer, I want to A/B test subject lines so that I can see which version gets a higher open rate. Acceptance: results split evenly across the send list and report open rate per variant after 24 hours.
- As a marketer, I want UTM parameters added automatically to campaign links so that I can track source performance without manual tagging. Acceptance: every outbound link in the campaign includes the correct campaign, source, and medium parameters.
Mobile
- As a mobile user, I want to receive a push notification when my order ships so that I don't have to check the app manually. Acceptance: notification fires within five minutes of the status change and deep-links to the order detail screen.
- As a mobile user, I want the app to remember my login so that I don't re-enter credentials every session. Acceptance: biometric login works on supported devices and falls back to password entry otherwise.
- As a mobile user with limited permissions granted, I want the app to explain why camera access is needed before prompting the system dialog. Acceptance: explanation screen appears once per feature before the native permission prompt.
Splitting Epics and Deciding Story Size
An epic like "users can manage their subscription" is too big to estimate or ship in one sprint. The fix is a vertical slice: a thin piece that touches every layer of the stack, front end to database, and delivers a complete, usable outcome, rather than a horizontal split like "build the database schema" followed separately by "build the UI," neither of which is shippable alone.
- Workflow slice: ship one path through the workflow first, like "cancel subscription" before "pause subscription" or "change plan."
- Data slice: handle one data type or segment first, like supporting only monthly billing before adding annual billing.
- Reduce acceptance scope: ship the core behavior now and defer edge cases, like supporting desktop checkout first and mobile checkout in a follow-up story.
- Spike then build: when the unknown is technical, not functional, timebox a research spike (one or two days, output is a decision or a prototype) and write the implementation as a separate, now-estimable story.
Story mapping helps you see where to cut before you start splitting blindly. Laying epics out as backbone activities across the top, with supporting tasks in rows beneath them, keeps the user's actual journey visible so a split preserves value instead of fragmenting it into disconnected tickets, a structure described in this guide to story mapping and MVP planning. Revisit scope after each slice ships. An MVP walking skeleton often reveals that the "nice to have" edge case you deferred was actually load-bearing, or that a feature you assumed was core barely gets used.
Common Anti-Patterns and Fast Fixes
Most story-writing problems repeat across teams. Here are the ones worth watching for in refinement.
- Too big to finish in a sprint: split by workflow or data slice rather than trying to estimate the whole thing at once.
- Too technical, no clear user benefit: either rewrite the "so that" clause with a real beneficiary, or drop the template and log it as a technical task.
- Vague role ("as a user"): name the actual persona, since "admin," "guest," and "power user" need different things even from the same feature.
- Missing or untestable acceptance criteria: add Given/When/Then clauses before the story enters a sprint, not after.
- Forcing unrelated work into the template: a bug fix or a chore doesn't need "as a... so that" wrapped around it. Log it plainly.
Pro Tip: If a story needs more than four acceptance criteria to feel "done," it's probably two stories.
Use shorthand or a plain task tag whenever the work has no distinct user-facing benefit, infrastructure, migrations, tooling, and let the user story template do its job only where a person's experience actually changes.
How Structured Planning Produces Sprint-Ready Stories
Stories get vague when the inputs behind them are vague. A story like "as a user, I want a dashboard" is a symptom of skipping the step where someone defines which user, what they're trying to accomplish, and why that feature made the priority list in the first place. Starting from a structured model, a defined ideal customer profile, a prioritized feature list, and a scoped build target, removes most of the guesswork before a single story gets written, because the role and the benefit are already decided upstream.
That's the gap a phase 0 planning layer is built to close: a one-line idea turned into a connected model covering target customers, competitors, and a prioritized feature set, which then becomes the raw material for a story bank rather than a blank page. When the feature list already carries priority and rationale, writing the acceptance notes is a matter of translating a decision that's already been made, not inventing one in the middle of refinement. For teams exporting into existing workflows, having that structure land in Notion or Confluence or sync to GitHub-ready tasks means the story bank doesn't sit disconnected from where the sprint actually happens. For a closer look at turning early planning into a working backlog, see this walkthrough of user story mapping for MVP builds.
A Note on Keeping Refinement Honest
My take after watching a lot of backlogs get cluttered: the discipline that matters most isn't the template, it's resisting the urge to over-specify a card before the conversation happens. A story card is supposed to be a placeholder for a discussion, not a contract. Acceptance criteria should evolve as the team learns something in refinement, and that's a feature, not a sign the story was written badly the first time.
A routine that works: a short weekly refinement session, rotating who writes the first draft of a story so the habit spreads beyond one person, and a hard timebox on any spike so an "unknown" doesn't quietly become a two-week detour. If you try a splitting pattern or acceptance format that works better than what's here, it's worth bringing to your next retro and seeing if the team adopts it.
— Karl
Try a Faster Path From Idea to Story Bank
Writing good stories gets a lot easier when the inputs are already structured. There are planning tools built around that exact problem: you type a one-line idea, and it turns into a connected model covering target customers, competitors, and a prioritized feature set, the same inputs this article uses to argue for clearer roles and sharper acceptance notes.
What that structure gives you directly feeds the story-writing work above.
- A defined customer profile means the "as a [role]" slot in every story is grounded, not guessed.
- A prioritized feature list means the backlog order is decided before refinement, not debated during it.
- A build spec and exports to Notion, Confluence, or GitHub-ready tasks mean the story bank lands where the sprint already happens, instead of staying stuck in a planning doc.
If you're starting from scratch or trying to turn a messy feature list into something a team can actually refine, our pricing page lays out the Free, Klaritea, and Pro plans so you can see which fits your stage before committing.
FAQ
What are the three C's of user stories?
The three C's are Card, Conversation, and Confirmation. The card is the short written story, the conversation is where the team fills in detail with stakeholders, and the confirmation is the acceptance criteria that prove the story is done, a structure reinforced by treating Gherkin-style criteria as that confirmation step.
What is considered a good user story?
A good user story is independent, negotiable, valuable, estimable, small, and testable, the INVEST checklist used widely in agile refinement. It names a specific role, a clear capability, and a real benefit, and it comes with acceptance criteria concrete enough to test.
How do you properly write a user story?
Start with the template "As a [role], I want [capability] so that [benefit]," naming a real persona rather than a generic "user." Then add two to four Given/When/Then acceptance criteria that describe exactly what proves the story is done, following guidance in the three-part template structure.
What are the three elements of a user story?
The three elements are the role (who benefits), the capability (what they need), and the benefit (why it matters), captured in the "As a... I want... so that..." format. Acceptance criteria are added afterward to make the story testable, but the role, capability, and benefit form the core sentence itself.
How do acceptance criteria differ from a Definition of Done?
Acceptance criteria are specific to one story and describe what makes that story complete, while the Definition of Done is a broader checklist that applies to every story regardless of content. Our Definition of Done guide breaks down how the two work together without duplicating each other.
Sources
- How to write effective Gherkin acceptance criteria
- Myth 4: In Scrum, the Product Backlog has to consist out of User Stories
- User Story Mapping: The Complete Guide to Backbone, Slicing, and MVP Planning (2026)