User Story Template
A user story template with acceptance criteria in Given/When/Then format, definition of done, and an INVEST checklist. Ready to paste into Jira or Linear. Free to copy, download, and use. No signup required.
# User Story Template **Feature:** [Feature Name] **Epic:** [Parent Epic, if applicable] **Sprint / Milestone:** [Sprint X / Q[X] Milestone] **Author:** [PM Name] **Status:** Draft / Refined / Ready for Dev --- ## User Story Format > **As a** [type of user], > **I want** [to perform some action], > **so that** [I can achieve some goal or benefit]. --- ## Story 1: [Short Story Name] **Story:** > As a **[user type]**, I want **[action]** so that **[benefit]**. **Priority:** P0 / P1 / P2 **Estimated effort:** [Story points or T-shirt size] **Dependencies:** [Any blockers or prerequisites] ### Acceptance Criteria **Scenario 1: [Happy path description]** - **Given** [initial context / precondition] - **When** [the user takes this action] - **Then** [the system responds with this outcome] **Scenario 2: [Edge case or error state]** - **Given** [context] - **When** [action] - **Then** [expected outcome] **Scenario 3: [Permission or role variation — if applicable]** - **Given** [user does not have permission / is not logged in / etc.] - **When** [they attempt the action] - **Then** [the system blocks or handles it correctly] ### Definition of Done - [ ] Unit tests cover the main scenarios - [ ] Acceptance criteria reviewed and approved by PM - [ ] Design matches approved Figma spec - [ ] No regressions in related flows - [ ] Analytics event fires correctly (if applicable) - [ ] Accessible at WCAG 2.1 AA level ### Notes & Open Questions - [Any implementation note or open question for engineering / design] --- ## Story 2: [Short Story Name] **Story:** > As a **[user type]**, I want **[action]** so that **[benefit]**. **Priority:** P0 / P1 / P2 **Estimated effort:** [Story points or T-shirt size] **Dependencies:** [Any blockers] ### Acceptance Criteria **Scenario 1: [Happy path]** - **Given** [context] - **When** [action] - **Then** [outcome] **Scenario 2: [Error state]** - **Given** [context] - **When** [action] - **Then** [outcome] ### Definition of Done - [ ] Unit tests cover the main scenarios - [ ] Acceptance criteria reviewed by PM - [ ] No regressions in related flows ### Notes - [Any note] --- ## Story 3: [Short Story Name] **Story:** > As a **[user type]**, I want **[action]** so that **[benefit]**. **Priority:** P0 / P1 / P2 ### Acceptance Criteria **Scenario 1:** - **Given** [context] - **When** [action] - **Then** [outcome] --- ## Good User Story Checklist (INVEST) - [ ] **Independent** — can be developed and delivered without requiring another story - [ ] **Negotiable** — the how is open to discussion between PM and engineering - [ ] **Valuable** — delivers clear value to a specific user - [ ] **Estimable** — engineering can give a rough size (if not, it needs breaking down) - [ ] **Small** — completable within one sprint - [ ] **Testable** — acceptance criteria are verifiable --- ## Related Artifacts - Design: [Figma link] - Epic: [Link to parent epic in Jira/Linear] - PRD: [Link to PRD] - Analytics spec: [Link]
How to use this User Stories template
Write the story before the criteria
The 'As a / I want / So that' format forces you to name the user, the action, and the benefit. If you can't fill in all three, the story isn't well-defined yet.
Write at least 3 scenarios per story
Happy path, error state, and a permission or edge case. Stories with only a happy path scenario regularly cause rework when engineers discover the edge cases during development.
Use the INVEST checklist before refinement
Run each story through the checklist before bringing it to sprint planning. Stories that fail the 'Small' check should be split. Stories that fail 'Testable' need more specific acceptance criteria.
Link to design and analytics specs
A story without a Figma link and an analytics event spec is incomplete. Engineers shouldn't have to guess what the design looks like or whether to add tracking.
Want a User Stories grounded in your actual customer data?
PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.
Frequently asked questions
What's the difference between a user story and a task?
A user story describes what a user needs and why — it belongs in planning and refinement. A task describes what an engineer does to implement a story — it belongs in sprint tickets. 'Allow users to export reports as PDF' is a user story. 'Add PDF generation library and wire up download button' is a task.
How many acceptance criteria should a story have?
Typically 2–5 scenarios. Fewer than 2 means you haven't thought through edge cases. More than 6 usually means the story is too big and should be split into smaller pieces.
Should user stories include technical implementation details?
No. User stories describe the 'what' and 'why', not the 'how'. Technical implementation is the engineering team's responsibility. If you're writing 'the system should use a REST API to call...', you're writing a technical spec, not a user story.
What's a good story point estimate?
Points measure relative complexity, not time. A 1-point story is trivially simple. An 8-point story is large and risky — it often needs to be split. Most healthy teams complete 2–5 point stories in a day or two. If your team consistently takes multiple sprints to complete stories, they're too large.
Other free templates