Product

User Story Template with Acceptance Criteria

The format is one line: As a [role], I want [capability] so that [outcome]. The line is the easy part. This template adds what makes a story buildable: Given/When/Then acceptance criteria, edge cases, what is out of scope, and an INVEST check before it enters a sprint.

Updated 2026-10-27

Copy and adapt

The template

User storyTemplate

[Short story title, verb first]

Story: As a [specific role], I want [capability] so that [outcome]. Epic: [[Epic name]] Priority: [Must / Should / Could] Estimate: [points or size, set by the team]

Context

[Why this matters now, with evidence: ticket count, quote, metric]
[Link to the PRD, research or design]

Acceptance criteria

Given [starting state], when [action], then [observable result].
Given [starting state], when [action], then [observable result].
Given [error or limit], when [action], then [what the user sees].

Edge cases

[Empty state, permissions, offline, very large input, concurrent edits]

Out of scope

[What this story does not cover, and where it is handled instead]

Notes for the team

Dependencies: [team, API, design]
Open questions: [question] (owner: [name])

Definition of done

Acceptance criteria pass
Tests added
[Analytics event, docs, release note]

5 examples

Examples for different situations

The same structure, filled in for the situations people actually bring to it. Copy the one closest to yours.

1.Consumer feature with full acceptance criteria

When it fits: Use this when the user is a member of the public, the happy path is obvious, and the real work is in the timing rules and failure cases the criteria have to pin down.

Consumer feature with full acceptance criteriaExample 1

Swap an out-of-stock item before the shopper picks it

Story: As a customer with a grocery order in progress, I want to choose a replacement when an item goes out of stock so that I do not receive a substitute I would never buy. Epic: [[Substitutions 2.0]] Priority: Must Estimate: 5 points

Context

18 percent of refunds in September were for unwanted substitutions; average refund $6.40
Shoppers start picking about 90 minutes before the delivery window

Acceptance criteria

Given my order has not started picking, when an item goes out of stock, then I get a push notification and up to 3 suggested replacements in the app.
Given I pick a replacement, when the shopper reaches that aisle, then the shopper's app shows my choice instead of their own suggestion.
Given I choose "No replacement", when the order is delivered, then the item is not charged and the receipt says "removed, out of stock".
Given I have not answered within 20 minutes, when picking starts, then the shopper's default substitution applies and I am told which one.

Edge cases

Replacement costs more: charge the difference only if it is under 20 percent, otherwise ask.
Notifications turned off: show the choice on the order screen.

Out of scope

Choosing replacements for items still in stock ("pre-approved substitutes"). Separate story.

Notes for the team

Dependencies: stock feed from the store system updates every 5 minutes, which sets the earliest we can notify.
Open questions: does "No replacement" refund delivery fees if the order drops below the minimum? (owner: Keiko)

Definition of done

All four criteria pass on iOS and Android
Event substitution_chosen with item and choice
Help center article updated

2.Admin and permissions story

When it fits: Use this when the user is an administrator, the change touches data other people own, and the acceptance criteria are mostly about who can see what afterwards.

Admin and permissions storyExample 2

Deactivate a teacher account without losing their gradebook

Story: As a school district administrator, I want to deactivate a teacher who has left so that they lose access immediately while their classes' grades stay available to the replacement teacher. Epic: [[District admin tools]] Priority: Must Estimate: 3 points

Context

Today admins delete the account, which hides the gradebook; support restored 27 gradebooks by hand last term
Mid-year departures peak in January

Acceptance criteria

Given an active teacher, when an admin selects Deactivate, then the teacher's sessions end within 1 minute and sign-in shows "This account has been deactivated by your district".
Given a deactivated teacher, when the admin assigns their classes to another teacher, then the new teacher sees all grades, comments and attachments, read and write.
Given a deactivated teacher, when a parent views a past report card, then the original teacher's name still appears on it.
Given an admin without the "Manage staff" permission, when they open a teacher profile, then the Deactivate option is not shown.

Edge cases

Teacher is co-teaching a class: the class stays with the co-teacher, no reassignment needed.
Admin deactivates themselves: blocked with a message.

Out of scope

Automatic deactivation from the HR system. Covered by the SIS sync epic.

Notes for the team

Dependencies: session revocation endpoint from the auth team (already in staging).

Definition of done

Criteria pass with a seeded district of 40 teachers
Audit log entry for every deactivation

3.Job story for a technical or operational need

When it fits: Use this when "As a user" does not fit because the person is an operator or the trigger is a situation, and forcing the standard format would hide what actually matters.

Job story for a technical or operational needExample 3

Alert finance when the nightly invoice export fails

Story (job story format): When the nightly invoice export to the bank fails, I want finance operations told within 15 minutes, so I can rerun it before the 09:00 bank cutoff. Epic: [[Billing reliability]] Priority: Must Estimate: 2 points

Context

The export failed silently 3 times since August; each time invoices went out a day late and 2 customers were charged late fees by their own banks
Finance operations is two people, Halvor and Chidi, who start at 07:30

Acceptance criteria

Given the export job exits with an error, when 15 minutes pass without a successful retry, then a message posts to #finance-ops with the error text and a rerun link.
Given the export produces a file with zero invoices on a business day, when the job finishes, then it is treated as a failure, not a success.
Given the rerun succeeds, when the file reaches the bank, then the same channel gets a confirmation with the invoice count.

Out of scope

Fixing the root causes of the failures. Each has its own bug.

Definition of done

Tested by forcing a failure in staging
Runbook updated with the rerun step

4.Epic split into three stories

When it fits: Use this when a feature is too big for one sprint and someone has proposed splitting it by layer (backend, frontend), which produces stories nobody can demo.

Epic split into three storiesExample 4

Epic: Recurring class bookings

Epic goal: Members of a fitness studio can book the same class every week instead of rebooking each Sunday night, when 60 percent of bookings happen in a 2-hour rush.

Story 1: Book a class weekly

Story: As a studio member, I want to book Tuesday 18:30 spin every week so that I keep my spot without rebooking.

Given a class with free spots, when I choose "Repeat weekly", then I am booked for the next 8 occurrences and see them in My bookings.
Given one of those occurrences is full, when I set up the series, then I am waitlisted for that date only and told which one. Estimate: 5 points

Story 2: Skip one week

Story: As a member with a recurring booking, I want to skip one date so that my spot is released without cancelling the series.

Given a recurring booking, when I skip a date more than 12 hours ahead, then the spot goes to the first person on the waitlist and I am not charged a late-cancel fee. Estimate: 2 points

Story 3: Cancel the series

Story: As a member, I want to cancel all future dates at once so that I do not have to cancel eight bookings one by one.

Given a recurring booking, when I cancel the series, then all future dates are released and past attendance is kept. Estimate: 1 point

Split rule used: by workflow step. Each story can ship and be demoed on its own; story 1 alone already removes the Sunday rush.

5.A story that fails INVEST, and the rewrite

When it fits: Use this in backlog refinement when a story arrives that everyone agrees with and nobody can estimate, and you need to show the team what is wrong with it.

A story that fails INVEST, and the rewriteExample 5

Before

Story: As a user, I want the dashboard to be faster so that I have a better experience.

INVEST check:

Independent: yes
Negotiable: yes
Valuable: probably, but for whom?
Estimable: no. Faster than what, on which page?
Small: no. "The dashboard" is 14 widgets and 3 data sources.
Testable: no. There is no number to test against.

After

Load the regional pipeline view in under 2 seconds

Story: As a regional sales manager, I want my region's pipeline view to load in under 2 seconds so that I can use it live in the Monday forecast call instead of exporting to a spreadsheet first. Priority: Should Estimate: 8 points (team, 2026-10-23)

Context

p95 load time for the pipeline view is 11.2 seconds for regions with more than 2,000 open deals; 9 of 12 regional managers export before the call

Acceptance criteria

Given a region with up to 5,000 open deals, when the manager opens the pipeline view, then it renders in under 2 seconds at p95, measured in production for a week.
Given the data is more than 15 minutes old, when the view loads, then it shows "Updated 14:05" so the manager knows.

Out of scope

The other 13 dashboard widgets. One story each if this one works.

The user story format, and what it leaves out

The standard user story template is one sentence: As a role, I want capability, so that outcome. It works because each part answers a question the team would otherwise guess at: who notices, what changes for them, and why it matters. But the sentence alone cannot be built. Two developers will read "I want to choose a replacement" and build two different things.

That is why the template above treats the story line as the headline and puts the work underneath it: acceptance criteria, edge cases and what is out of scope.

Check every story against INVEST

Before a story goes into a sprint, run it through the six letters. One line each is enough.

Independent. It can ship without another unfinished story. If two stories must ship together, they may be one story.
Negotiable. It describes the outcome, not the implementation. The team can propose a different solution.
Valuable. A real person notices when it ships. "Refactor the export module" is a task, not a story, unless you can say who benefits.
Estimable. The team can size it. If they cannot, something is missing: usually the role, a number, or a dependency.
Small. It fits in a sprint, ideally in a few days. If not, split it (see below).
Testable. Someone who did not write it can check whether it is done. The acceptance criteria are the test.

The last example on this page shows a story everyone agreed with failing three of the six.

Write acceptance criteria that can fail

Good criteria describe observable behavior, include at least one failure case, and contain a number wherever the story implies one.

Given/When/Then works well because it forces a starting state. "Given my order has not started picking" rules out a whole class of arguments.
Write the failure case on purpose. What happens when the user does not answer, the input is too large, or they lack permission? Most bugs live there.
Put numbers in. "Loads fast" cannot fail; "renders in under 2 seconds at p95" can.
Keep the criteria about this story. Tests, code review and documentation belong in the team's definition of done, not in each story.

Split stories by what the user can do

When a story is too big, split it so each piece is still valuable on its own. Splitting by workflow step (book, skip, cancel) is the most common. Others: by rule (standard price first, discounts later), by data (one region first), or by happy path first and failure handling second. Avoid splitting by layer or by role in the team; the result is stories nobody can demo.

User stories, PRDs and tasks

A story is the unit of work the team estimates. A PRD sits above it and holds the problem, goals and non-goals for a whole feature, which then breaks down into stories. Tasks sit below a story: the technical steps a developer lists while building it. A bug is not a story; use the bug report template so the steps to reproduce are not lost.

Common mistakes

"As a user". The most common story opening and the least useful.
The solution in the I want. "I want a dropdown" removes the team's chance to suggest something better.
No failure cases. The happy path gets built, the edge cases get found in production.
Acceptance criteria written after the sprint starts. Then they describe what was built, not what was needed.
Decisions from refinement left in chat. Write the answer into the story, or into Out of scope, the same day.

Customization tips

Name a real role, not "a user"
"As a user" usually means nobody asked who this is for. Use the role that will notice the change: a shopper with an order in progress, a district admin, a regional sales manager. The acceptance criteria get sharper as soon as the role does.
Never skip the so that
The outcome clause is what lets the team pick a better solution than the one you described. A team that knows the goal is "use it live in the Monday call" might cache the view instead of rewriting it.
Use a job story when there is no user
For operational and technical work, write "When [situation], I want [motivation], so I can [outcome]". It keeps the why without inventing a persona, as the third example shows.
Three to five acceptance criteria
Fewer than three usually means the failure cases are missing. More than five usually means the story should be split. Each criterion should be checkable by someone who did not write the story.
Split by workflow, not by layer
"Backend for recurring bookings" and "frontend for recurring bookings" cannot be demoed separately. Split by what the user can do: book weekly, skip a week, cancel the series. Each one ships.

In the app

How to do this in Scribelet

Open Desk Settings, then Templates, tap Add Template and paste the template above, with category Planning and #story as a default tag. Every new story starts from the same structure.
Link each story to its epic with [[Substitutions 2.0]]. The epic note's backlinks panel then lists every story under it, which is a quick way to see whether an epic has quietly grown.
Turn the Definition of done into checkboxes with a date, like - [ ] Help center article updated @due(2026-11-20). Unticked items appear in the Tasks view until done.
Ask the AI chat "what did we decide about substitution price limits?" and it answers from your stories and refinement notes with citations.
If you write stories ahead of coding, connect Scribelet's MCP server to Claude Code or Cursor so the agent can read the story and its acceptance criteria directly.

Templates, template variables and AI generation are documented in Note templates.

Frequently asked questions

Can you give an example of a good user story?

"As a school district administrator, I want to deactivate a teacher who has left so that they lose access immediately while their classes' grades stay available to the replacement teacher." It names a specific role, a capability and an outcome, and it comes with four Given/When/Then acceptance criteria. All five examples above are written to that standard, and the last one shows a weak story rewritten.

What is the recommended format for writing user stories?

The three-part format: As a [role], I want [capability] so that [outcome]. Add acceptance criteria in Given/When/Then form underneath. For operational work with no obvious user, the job story format (When [situation], I want [motivation], so I can [outcome]) often fits better.

How do I write a user story in Jira?

Create an issue of type Story, put a short verb-first title in Summary, and paste the story line, acceptance criteria and out of scope into Description. The template above is plain Markdown, so it pastes into Jira, Linear, Azure DevOps or a GitHub issue. Link the story to its epic in the tracker's epic field.

How do business analysts write user stories?

The same way, with more weight on acceptance criteria and edge cases. A BA usually drafts the story from stakeholder interviews, writes the criteria in Given/When/Then so testers can use them directly, and brings it to refinement where developers estimate and challenge it. The story is a placeholder for that conversation, not a replacement for it.

What does INVEST mean for user stories?

Independent, Negotiable, Valuable, Estimable, Small and Testable, a checklist coined by Bill Wake. A story that fails Estimable or Testable is the most common problem in practice: it usually lacks a number or a specific role. The last example on this page shows an INVEST check done line by line.

What is the difference between acceptance criteria and the definition of done?

Acceptance criteria are specific to one story: what this feature must do. The definition of done applies to every story: tests written, code reviewed, docs updated. A story is finished when both are met.

Stories that still make sense when someone picks them up

Save this user story template in Scribelet, link every story to its epic, and keep the decisions from refinement next to the criteria they changed. Encrypted, free to start.

Write your first user story

or get the app

Download on theApp Store

Free plan, no credit card. See pricing

Product

PRD Template (Product Requirements Document)

A PRD (product requirements document) says what problem a release solves, for whom, how you will know it worked, and what it deliberately will not do. This template keeps it short enough to be read, and adds what most PRD templates leave out: a status, a decision log, and open questions with owners and dates.

Product

Sprint Planning Template

Sprint planning goes wrong in two places: the team commits to last sprint's velocity with this sprint's people, and unfinished work rolls over without anyone deciding it should. This template does the capacity math in the open, makes a decision on every carried-over item, and ends with a sprint goal someone could check on demo day.

Product

Bug Report Template

A good bug report lets someone who has never seen the problem make it happen on their own machine. This template covers the fields every bug report template has (steps, expected, actual, environment, severity) and adds the ones most leave out: how often it reproduces, whether it is a regression, and the workaround.

Product

Product Roadmap Template

A roadmap is a promise about priorities, not a schedule. This template ties every initiative to a goal, says how confident you are in each date, keeps a visible list of what you are not doing, and logs every change with its reason. Copy it as-is, or start from the roadmap example closest to your audience.

Product

User Interview Template

A user interview note is only useful if a teammate can tell what the participant said from what you concluded. This template keeps verbatim quotes, observed behavior and your interpretation in separate sections, ends with a three-line snapshot, and links every session to one study note for synthesis.

Article

Definition of done

From the Scribelet blog