What is the user story format?

The standard user story format is: 'As a [specific persona], I want to [specific action] so that [specific outcome].' A complete user story also includes a Definition of Done (what must be true for this story to be complete), acceptance criteria (3–5 Given/When/Then statements), and a story point estimate. Stories without acceptance criteria produce a sprint's worth of back-and-forth between PM and engineering.

What is the difference between a user story and an acceptance criterion?

A user story captures the who, what, and why at a high level: 'As a returning user, I want to reset my password so that I can access my account.' An acceptance criterion is a specific, verifiable condition: 'Given a user submits a valid email, when they click submit, then they receive a reset email within 60 seconds.' Acceptance criteria operationalize the story — they define exactly when engineering can consider the story done.

How many acceptance criteria should a user story have?

Three to five acceptance criteria per story is the practical range. Fewer than 3 means the story is underspecified — QA will have to invent test cases. More than 7 usually means the story is too large and should be split. Each criterion must be testable by a QA engineer without asking the PM for clarification.

What is a Definition of Done in a user story?

The Definition of Done (DoD) states what must be true for the story to be considered complete — beyond just the code being written. It typically includes: code reviewed, tests passing, accessibility checked, analytics events firing, and the product behavior matching the acceptance criteria. The DoD is agreed on at the team level and applied to every story, not written per-story.

How do you split a large user story?

Split on four boundaries: (1) persona — one story per user type if they have meaningfully different needs; (2) happy path vs. edge cases — ship the happy path first, handle edge cases in a follow-on story; (3) integration vs. core feature — ship the feature working without the integration, then add the integration; (4) data entry vs. data display — these often have different engineering complexity and can ship independently.

User Story Template: The Format Engineers Actually Use

A user story follows a single format: "As a [persona], I want to [action] so that [outcome]." A well-written user story includes the story statement, a Definition of Done, three to five acceptance criteria, and a story size estimate. Stories without acceptance criteria produce a sprint's worth of back-and-forth between PM and engineering. This template prevents that.

47%

of sprint delays traced to user stories with missing acceptance criteria

3×

faster sprint planning when stories include Definition of Done

The user story template

As a [specific persona — not "user"],

I want to [specific action — verb + object],

So that [specific outcome — the why, not the what].

Definition of Done: [What must be true for this story to be considered complete?]

Acceptance criteria:

1. Given [context], when [action], then [observable outcome].

2. Given [context], when [action], then [observable outcome].

3. Given [context], when [action], then [observable outcome].

Story points: [1 / 2 / 3 / 5 / 8 — Fibonacci. If above 8, split the story.]

15 real user story examples

Authentication

As a returning user who forgot my password, I want to reset it from the login screen without contacting support so that I can access my account in under two minutes.

DoD: User can initiate and complete a password reset without any support interaction. Reset link expires after 15 minutes. Link is single-use.

AC: Given a user submits a valid email, when they click submit, then they receive a reset email within 60 seconds.

AC: Given a user clicks an expired reset link, when they land on the reset page, then they see an expiry message and a "request a new link" button.

Onboarding

As a new user setting up my account for the first time, I want to connect my Slack workspace in under 3 steps so that I can start generating PRDs from Slack threads immediately.

DoD: User can connect Slack and generate their first PRD from a Slack thread without leaving the onboarding flow. Success measured by: Slack-connected users who generate a PRD within first session ≥ 60%.

AC: Given a new user clicks "Connect Slack," when they complete OAuth, then they are returned to the onboarding flow with Slack shown as connected.

AC: Given Slack is connected, when a user pastes a Slack thread URL, then the PRD generator pre-fills from the thread content within 5 seconds.

Core feature

As a product manager with a rough idea, I want to generate a complete 10-section PRD from a voice note transcript so that I can skip the blank-page problem and spend my time reviewing rather than writing.

DoD: Generated PRD includes all 10 sections with specific, non-placeholder content. Generation time under 35 seconds.

AC: Given a user pastes a voice note transcript of 100–2,000 words, when they click Generate, then a PRD is produced with all 10 sections in under 35 seconds.

AC: Given the generated PRD, when a user reviews the edge cases section, then at least 4 edge cases are listed with specific failure scenarios (not generic placeholders).

Export and integration

As a PM who uses Linear for sprint planning, I want to export a generated PRD's user stories as Linear issues with one click so that I don't manually copy content between tools.

DoD: All user stories from the PRD are created as Linear issues. Each issue includes the story text as the description and the acceptance criteria as sub-items. Issues are created in the user's selected Linear project.

AC: Given a user clicks "Export to Linear," when the export completes, then each user story appears as a Linear issue in the selected project within 30 seconds.

AC: Given a Linear export, when the user opens a created issue in Linear, then the acceptance criteria appear as a checklist in the issue description.

Settings and preferences

As a PM who writes PRDs for a fintech product, I want to set a default industry context so that every PRD I generate includes compliance and regulatory edge cases relevant to financial services without re-specifying it each time.

DoD: User can save an industry context that persists across sessions and is automatically applied to all subsequent generations.

AC: Given a user saves "Fintech / Payments" as their industry context, when they generate a new PRD, then the edge cases section includes at least 2 regulatory edge cases (e.g., payment fraud, AML requirements).

The five most common user story mistakes

Mistake	Example	Fix
Generic persona	"As a user..."	Name the specific persona: "As a returning user who forgot their password..."
Action is a feature, not a goal	"I want a dashboard..."	"I want to see my key metrics in one place so that I don't open 4 different tabs..."
Missing "so that"	Story ends after the action	The "so that" captures the why — without it, engineering can't make tradeoff decisions
No acceptance criteria	Story has no criteria	Write a minimum of 3 Given/When/Then criteria before the story enters the sprint
Story too large	8+ story points	Split on the persona, the happy path vs. edge cases, or the integration vs. the core feature