A user story template gives your product team one short, repeatable way to capture what a user wants and why. The format is small on purpose. Three lines, plus acceptance criteria, plus a title. Done well, a story slots into a sprint and a tester can verify it without asking. Done badly, it reads like a technical task with "As a user" stapled to the front.
This post gives you a copy-paste user story template, walks through INVEST criteria, shows five worked examples across different feature types, and compares the user story format with the job story and use case alternatives. User stories are the smallest unit in agile, but they sit inside a larger doc trail. They get rolled up into a PRD template, inform the engineering design doc template that follows, and feed the sprint retrospective template when the work ships. If you're standardizing process docs across the team, this fits next to the post-mortem template and the runbook template.
What is a user story?
A user story is the smallest unit of work in an agile framework. It describes a single piece of functionality from the perspective of the person who will use it, in plain language, in one to two sentences. The team uses the story as a placeholder for a conversation, not a complete spec.
Atlassian's definition is the one most teams quote: a user story is "an informal, general description of a software feature written from the end user's or customer's perspective." The work of fleshing it out, with acceptance criteria and technical details, happens during sprint planning and refinement.
Stories don't replace requirements. They frame them. The requirements come later, once the team agrees on the goal.
The standard user story template
The format almost every agile team has converged on is three parts: persona, want, benefit. It looks like this:
Title: [Short, descriptive name]
User Story:
As a [type of user],
I want to [perform some action],
so that [I get some value or benefit].
Acceptance Criteria:
- Given [some context],
when [some action is taken],
then [an observable outcome should occur].
- Given [another context],
when [another action is taken],
then [another outcome should occur].
Optional fields:
- Priority: [High / Medium / Low]
- Estimate: [Story points or t-shirt size]
- Dependencies: [Other stories or tickets]
- Notes: [Open questions, links to mockups]
The three parts of the story line each carry weight. The persona answers who. The "want" answers what they're trying to do, in their words, not yours. The "so that" answers why it matters to them, which is the part most teams skip and most teams regret skipping. Without the benefit, it's hard to tell whether the story should be done, descoped, or rewritten.
Acceptance criteria use the Given/When/Then pattern from behaviour-driven development. They define what "done" means for that story and double as the test cases QA will write. A story without acceptance criteria is a wish.
The INVEST criteria for a good user story
Bill Wake's INVEST acronym has been the standard quality check for user stories since 2003. It still holds up. Each letter is one property a good story should have.
Independent. The story can be built and shipped without waiting on another story. If two stories must ship together, they should probably be one story or one epic.
Negotiable. The story is a conversation starter, not a contract. Details can change during sprint planning without rewriting the whole thing.
Valuable. The story delivers value to a real user or customer. If the only reason to build it is "engineering needs it for the database migration," it's a technical task, not a user story. That's fine, just label it correctly.
Estimable. The team can estimate it within a sprint. If they can't, the story is too vague or too large. Break it down or add detail until estimation is possible.
Small. It fits inside one sprint, comfortably. A story that needs a whole quarter is an epic. Slice it.
Testable. Acceptance criteria exist and a tester can verify them without asking the author. If you can't write Given/When/Then for it, you don't know what done looks like yet.
When a story fails INVEST, you fix it before pulling it into a sprint, not during the sprint. Most failed sprints can be traced back to a story that should have been split or sharpened during refinement.
Five worked user story examples
Templates are easier to copy than to interpret. Here are five examples covering the categories most product teams write stories for.
Example 1: B2B SaaS feature
Title: Bulk-invite teammates from CSV
User Story:
As an admin onboarding a new team,
I want to invite up to 200 teammates by uploading a CSV,
so that I don't have to send invite emails one at a time.
Acceptance Criteria:
- Given I am on the team settings page,
when I upload a CSV with email addresses in the first column,
then each unique email receives an invitation email within 60 seconds.
- Given the CSV contains rows with invalid emails,
when I upload the file,
then the system shows a validation summary listing the invalid rows
and still sends invites to the valid ones.
- Given I upload more than 200 rows,
when validation runs,
then I see an error explaining the limit and no invites are sent.
Priority: High
Estimate: 5 points
This story passes INVEST. It's independent of other onboarding work, small enough for a sprint, and testable from the criteria alone.
Example 2: Consumer feature
Title: Resume the last podcast episode
User Story:
As a daily listener,
I want the app to resume the episode I was on when I left,
so that I don't have to scroll my history every morning.
Acceptance Criteria:
- Given I closed the app mid-episode,
when I reopen the app within seven days,
then the home screen shows a "Resume" card with the episode and exact timestamp.
- Given I finished the episode,
when I reopen the app,
then the resume card is replaced with a recommendation card.
The benefit clause here, "so that I don't have to scroll my history every morning," is what makes this a real story instead of a feature spec. It tells the team this is about reducing friction for habitual users, which informs design choices the criteria don't cover.
Example 3: Internal tool
Title: Slack alert for failed Stripe webhooks
User Story:
As an on-call engineer,
I want a Slack alert when a Stripe webhook fails three times in a row,
so that I can fix billing issues before the customer notices.
Acceptance Criteria:
- Given a webhook from Stripe returns a 5xx response three consecutive times,
when the third failure is logged,
then a message is posted to #billing-alerts with the event ID and the last error.
- Given the webhook recovers on the fourth attempt,
when the success is logged,
then a follow-up message is posted to the same thread marking it resolved.
Priority: Medium
Estimate: 3 points
Internal-tool stories often get written as raw tasks ("Add Slack alert for webhook failures"). The story format forces the writer to name the persona and the benefit, which is how you catch stories that don't actually have a user.
Example 4: Technical debt as a user-facing improvement
Title: Faster dashboard load on first paint
User Story:
As a returning customer,
I want my dashboard to load in under 1.5 seconds,
so that I can check today's numbers before my standup starts.
Acceptance Criteria:
- Given a returning customer with a populated dashboard,
when they navigate to /dashboard,
then time to first contentful paint is under 1.5 seconds at the 75th percentile
measured over a 7-day rolling window.
- Given the customer has no data yet,
when they navigate to /dashboard,
then the empty state renders in under 800ms.
Technical debt is often easier to fund when it's framed as a user story. The persona makes the benefit concrete. "Refactor dashboard query layer" is a no for the product owner. "Returning customer wants 1.5-second load" is a yes.
Example 5: A bad story, fixed
Here's a story that fails INVEST, alongside the rewrite.
Original (fails Independent, Small, Testable):
As a user, I want a better checkout experience so that I can buy faster.
Rewritten as three smaller stories:
Story A: Save default shipping address
As a returning customer,
I want my default shipping address pre-filled at checkout,
so that I don't retype it every order.
Story B: One-click reorder
As a returning customer,
I want a "buy again" button on past orders,
so that I can repeat an order without rebuilding the cart.
Story C: Apple Pay at checkout
As a mobile customer,
I want to pay with Apple Pay,
so that I can finish checkout without typing card details.
The original story is too large, has a vague persona, and offers no testable criteria. The three replacements each fit a sprint and each have an obvious "done."
How to write good acceptance criteria
Acceptance criteria turn a story from a wish into a verifiable contract. Two formats are common, and most teams pick one and stick with it.
The Given/When/Then format is the more rigorous option. It maps cleanly to automated tests and is the format Atlassian, Aha, and most BDD shops recommend. Each scenario starts with the context (Given), names the action (When), and states the observable outcome (Then). One scenario per case, including the edge cases.
The checklist format is lighter. Each item is a single bullet that must be true for the story to ship.
Acceptance Criteria (checklist style):
- The CSV upload button accepts .csv files only.
- Invalid email rows are flagged in a validation summary.
- A confirmation toast appears when invites are sent.
- The 200-row limit is enforced and shown in an error if exceeded.
Checklists are faster to write but harder to test against. Most teams that scale up move to Given/When/Then once they have more than two or three engineers writing stories.
User story vs job story vs use case
User stories are not the only format. Two alternatives have real adherents, and they describe slightly different things.
| Format | Structure | When it shines |
|---|---|---|
| User story | "As a [persona], I want [action], so that [benefit]." | Most agile teams. Strong default for sprint-based work where the persona matters. |
| Job story | "When [situation], I want to [motivation], so I can [expected outcome]." | When persona is unclear or misleading. Focuses on the situation triggering the need. |
| Use case | Numbered actor-system interaction with main flow, alternate flows, exceptions. | Heavier requirements work, regulated industries, complex multi-step flows. |
Job stories, popularized by Intercom's product team, drop the persona on purpose. Their argument is that two different personas can have the same job to be done, and naming the persona narrows the design unhelpfully. "When my team grows past five people, I want to set role-based permissions, so I can stop bottlenecking on admin tasks" applies to a startup founder and an enterprise IT manager equally.
Use cases come from the older requirements engineering tradition. They're more thorough, with main success scenarios, alternate flows, and exception flows numbered out. Heavier, but useful when the cost of getting it wrong is high (medical devices, banking, anything regulated).
For a fast-moving SaaS team, the user story is still the right default. Switch to job stories when persona-led design feels narrow. Reach for full use cases when compliance demands it.
Common mistakes that ruin user stories
A handful of mistakes show up over and over in story reviews.
Writing technical tasks as stories. "As a developer, I want to refactor the auth module, so that the code is cleaner." This is a task, not a user story. The persona is wrong (no end user), the benefit is internal, and there's no testable outcome. Label it as tech debt and skip the story format.
Skipping the "so that" clause. A story without a benefit is a feature request. Without the why, the team can't tell whether the story is worth doing, whether the design is on target, or whether to descope when the sprint runs hot.
Stories the size of an epic. "As a user, I want a mobile app." That's a quarter of work, not a sprint. Slice it by user journey, by platform, by entry point, until each piece fits inside one sprint.
Acceptance criteria that aren't testable. "The page should be fast." Fast for whom, measured how, at what percentile? Numbers in acceptance criteria are not optional.
Overlapping stories. Two stories that can't ship independently are one story (or one epic with smaller children). If shipping story A without B leaves the user with a broken feature, the slice is wrong.
Persona inflation. "As a user, I want X" applies to nobody. Pick a real persona: returning customer, on-call engineer, free-trial admin, mobile-first viewer. Specificity drives design.
Where user stories live, and why most of them disappear
Most user stories live in a tracker like Jira, Linear, or Shortcut. That's the right home for active sprint work. Once the story ships and the ticket closes, it gets archived, and six months later nobody remembers why the team built it the way they did.
This is the same problem PRDs and design docs have, scaled down. The decision context that lives in tickets evaporates when the ticket closes. For active sprint work, that's fine. For institutional memory, it's expensive.
The teams that don't lose this context keep a parallel record: shipped stories rolled up into the relevant PRD, linked from the design doc, searchable alongside other product specs. Tools like Docsio make it easy to spin up an internal product spec archive that holds the PRDs, the design docs, and the user stories that fed them, with full-text search across the lot. The tracker stays the system of record for in-flight work, and the docs site becomes the system of record for "why did we build it that way?" three quarters later.
The next step depends on what you're doing with the story. If it's the start of a new feature, it likely belongs inside a PRD template that gives it strategic context. If it's already approved and engineering needs to design the implementation, the receiver is the design doc template. And once the story ships, it should appear in your release notes template so customers know what changed.
User story template FAQ
What is the format of a user story?
The standard format is three parts: "As a [type of user], I want to [perform an action], so that [I get some benefit]." Most teams add a short title and acceptance criteria written in Given/When/Then form. The format is small on purpose, since the story is meant to start a conversation, not replace a spec.
What are the 3 C's of a user story?
The 3 C's are Card, Conversation, and Confirmation. The Card is the short written description on the ticket. The Conversation is the team discussion that fills in details during refinement and planning. The Confirmation is the acceptance criteria that defines when the story is complete and how it will be tested.
What is a good example of a user story?
A good example is specific in persona and outcome. "As a returning customer, I want my default shipping address pre-filled at checkout, so that I don't retype it every order." The persona is concrete, the action is testable, and the benefit explains why it matters. Pair it with two or three Given/When/Then acceptance criteria.
How do you write a user story?
Start with the persona, write the want in their words, then state the benefit. Keep it to one or two sentences. Run it through INVEST: independent, negotiable, valuable, estimable, small, testable. If it fails any of those, refine the wording or split the story. Then add acceptance criteria before pulling the story into a sprint.
What is the difference between a user story and a use case?
A user story is a short, informal description of a feature from the user's perspective, designed to start a conversation. A use case is a more thorough document covering the actor, the system, the main success flow, alternate flows, and exception flows. Stories suit fast-moving agile teams. Use cases suit heavier requirements work like regulated industries.
Closing the loop
The user story template is small because the work it points at is small. Three lines for the story, a few Given/When/Then scenarios for the acceptance criteria, a title, an estimate. Anything more and you're writing a PRD. Anything less and you're writing a wish.
The format is the easy part. The discipline is in running every story through INVEST before it enters a sprint, writing acceptance criteria that a tester can verify without asking the author, and keeping a record of shipped stories somewhere your future self can find them. The teams that get user stories right aren't writing fancier templates. They're using a plain one, consistently, with real personas and real benefits.
If you want every PM and engineer on the team writing in the same shape, paste the template at the top of this post into your tracker, link it from your engineering handbook, and require it for every story heading into refinement. Six sprints in, the format becomes invisible and the conversations get sharper.