What This Template Is For
A user story is a short description of a feature written from the perspective of the person who will use it. Stories are the basic unit of work in most agile teams. They replace long spec documents with small, testable increments that can be estimated, prioritized, and delivered in a single sprint.
The problem is that most user stories are either too vague ("As a user, I want a better experience") or too prescriptive ("As a user, I want a blue button at 14px in the top-right corner"). A good story sits in between: specific enough that engineering can build it, open enough that design can solve it, and small enough that QA can test it within a sprint. This template gives you the format, quality checklist, and splitting techniques to write stories at that sweet spot consistently.
Use this template alongside the Sprint Planning Template to build sprint backlogs. For prioritizing which stories to tackle first, the RICE Calculator or MoSCoW Prioritization Template can help rank your backlog. If you are building stories from a larger initiative, start with the PRD Template and break it down into stories using the splitting techniques below.
How to Use This Template
- Start with the user role. Who is performing this action? Use a specific persona or role, not "user."
- Describe the action. What does this person want to do? Write it as a capability, not a task.
- State the benefit. Why does this matter to them? The benefit connects the story to user value.
- Write acceptance criteria. These are the conditions that must be true for the story to be considered done. Use the Given/When/Then format for clarity.
- Run the INVEST checklist. Every story should pass all six criteria before going into a sprint.
- Split stories that are too large. If a story cannot be completed in a single sprint, use the splitting techniques below.
- Add the story to your backlog. Include priority, estimate, and any dependencies.
The User Story Format
Standard Format
As a [specific user role],
I want to [perform an action or have a capability],
So that [I achieve a specific benefit or outcome].
Story Card Template
| Field | Value |
|---|---|
| Story ID | [US-XXX] |
| Title | [Short, descriptive name] |
| User Story | As a [role], I want to [action], so that [benefit]. |
| Priority | P0 (Must Have) / P1 (Should Have) / P2 (Nice to Have) |
| Estimate | [Story points or T-shirt size] |
| Sprint | [Sprint number or "Backlog"] |
| Dependencies | [Other story IDs this depends on, or "None"] |
| Labels | [Feature area, epic, or theme] |
Acceptance Criteria Format
Use the Given/When/Then format. Each story should have 3-6 acceptance criteria.
Given [a specific precondition or context],
When [the user performs a specific action],
Then [a specific, observable outcome occurs].
Additional criteria checklist:
- ☐ Happy path is covered (the expected behavior)
- ☐ At least one error/edge case is covered
- ☐ Performance requirements are stated if relevant
- ☐ Accessibility requirements are stated if relevant
- ☐ Data validation rules are defined if the story involves input
The INVEST Checklist
Run every user story through this checklist before adding it to a sprint. A story that fails more than one criterion needs rework.
| Criterion | Question | Pass? |
|---|---|---|
| Independent | Can this story be built and delivered without waiting for another story to finish first? | - ☐ |
| Negotiable | Is the implementation approach open to discussion between PM, design, and engineering? | - ☐ |
| Valuable | Does this story deliver value to the user (not just to the team internally)? | - ☐ |
| Estimable | Can the engineering team estimate this story with reasonable confidence? | - ☐ |
| Small | Can this story be completed within a single sprint? | - ☐ |
| Testable | Can QA write a test to verify whether this story is done or not done? | - ☐ |
Common INVEST failures and fixes:
| Failure | Symptom | Fix |
|---|---|---|
| Not Independent | "We cannot start this until story X is done" | Split into a smaller story that can be built independently, or sequence them across sprints |
| Not Estimable | "We have no idea how long this will take" | Create a spike (time-boxed research task) first to reduce uncertainty |
| Not Small | "This will take 3 sprints" | Use the splitting techniques below |
| Not Testable | "As a user, I want a good experience" | Rewrite with specific, measurable acceptance criteria |
Story Splitting Techniques
When a story is too large for a single sprint, split it using one of these patterns.
1. Split by Workflow Step
Break a multi-step workflow into one story per step.
- Original: "As a user, I want to create and share a report"
- Split: "As a user, I want to create a report" + "As a user, I want to share a report via email"
2. Split by User Role
If different roles have different needs, write separate stories.
- Original: "As a team member, I want to manage notifications"
- Split: "As an admin, I want to configure notification rules" + "As a team member, I want to receive notifications"
3. Split by Input Method
Separate different data entry paths.
- Original: "As a user, I want to import contacts"
- Split: "As a user, I want to import contacts from a CSV file" + "As a user, I want to import contacts from Google Contacts"
4. Split by Business Rule
Isolate complex business logic into separate stories.
- Original: "As a user, I want to see my billing summary"
- Split: "As a user, I want to see my current plan and usage" + "As a user, I want to see prorated charges for mid-cycle plan changes"
5. Split by Happy Path vs. Edge Cases
Ship the core behavior first, then handle exceptions.
- Original: "As a user, I want to upload a profile photo"
- Split: "As a user, I want to upload a JPEG or PNG profile photo" + "As a user, I want to see an error message if my uploaded file is not a supported format"
Filled Example: B2B Notification System (5 Connected Stories)
These five stories are part of a single epic: "Notification Preferences for Team Accounts." They demonstrate how to break an initiative into independent, sprint-sized stories.
Story 1: View Notification Settings
| Field | Value |
|---|---|
| Story ID | US-401 |
| Title | View notification preferences page |
| User Story | As a team member, I want to view my current notification settings in one place, so that I know which notifications I am receiving and through which channels. |
| Priority | P0 (Must Have) |
| Estimate | 3 points |
| Sprint | Sprint 14 |
| Dependencies | None |
| Labels | Notifications, Settings |
Acceptance Criteria:
- Given I am logged in, When I navigate to Settings > Notifications, Then I see a list of all notification categories (Comments, Mentions, Status Changes, Due Dates, Weekly Digest) with their current on/off state.
- Given I am on the notification settings page, When I view a notification category, Then I see which channels are enabled (In-app, Email, Slack) for that category.
- Given I am on the notification settings page, When the page loads, Then it loads within 1 second and displays my current saved preferences.
Story 2: Toggle Individual Notification Categories
| Field | Value |
|---|---|
| Story ID | US-402 |
| Title | Toggle notification categories on/off |
| User Story | As a team member, I want to turn individual notification categories on or off, so that I only receive notifications that are relevant to my work. |
| Priority | P0 (Must Have) |
| Estimate | 5 points |
| Sprint | Sprint 14 |
| Dependencies | US-401 (settings page must exist) |
| Labels | Notifications, Settings |
Acceptance Criteria:
- Given I am on the notification settings page, When I toggle a notification category off, Then the system stops sending me notifications of that type within 30 seconds.
- Given I toggle a notification category off, When I refresh the page, Then the toggle reflects the saved off state.
- Given I am on the notification settings page, When I toggle Mentions off, Then I see a confirmation message: "You will no longer receive mention notifications. You can re-enable this at any time."
- Given I have all notification categories toggled off, When I try to toggle the last one off, Then the system allows it (no forced minimum).
Story 3: Choose Notification Channels Per Category
| Field | Value |
|---|---|
| Story ID | US-403 |
| Title | Set notification channel per category |
| User Story | As a team member, I want to choose which channel (in-app, email, or Slack) I receive each notification type through, so that urgent notifications reach me immediately while less important ones go to email. |
| Priority | P1 (Should Have) |
| Estimate | 5 points |
| Sprint | Sprint 15 |
| Dependencies | US-402 (toggle must work) |
| Labels | Notifications, Settings, Slack |
Acceptance Criteria:
- Given a notification category is toggled on, When I click the channel options, Then I see checkboxes for In-App, Email, and Slack (if Slack integration is connected).
- Given Slack integration is not connected, When I view channel options, Then the Slack checkbox is disabled with a tooltip: "Connect Slack in Integrations to enable."
- Given I select Email and Slack for the Comments category, When someone comments on my item, Then I receive the notification in both channels within 60 seconds.
- Given I select only In-App for Due Dates, When a due date triggers, Then I receive an in-app notification and no email or Slack message.
Story 4: Admin Default Notification Settings
| Field | Value |
|---|---|
| Story ID | US-404 |
| Title | Admin sets default notification preferences for new team members |
| User Story | As a team admin, I want to set default notification preferences for new members who join my workspace, so that new hires start with sensible defaults instead of all notifications on. |
| Priority | P1 (Should Have) |
| Estimate | 3 points |
| Sprint | Sprint 15 |
| Dependencies | US-403 (channel selection must work) |
| Labels | Notifications, Admin, Settings |
Acceptance Criteria:
- Given I am a workspace admin, When I navigate to Admin > Notification Defaults, Then I see the same notification settings interface as individual users, with a header: "These settings apply to new team members."
- Given I save default settings, When a new user joins the workspace, Then their notification preferences are pre-populated with the admin defaults.
- Given a new user joins with admin defaults applied, When they navigate to their own notification settings, Then they can override any default. Their individual settings take precedence.
Story 5: Quiet Hours
| Field | Value |
|---|---|
| Story ID | US-405 |
| Title | Set quiet hours for notifications |
| User Story | As a team member, I want to set quiet hours during which I do not receive push or Slack notifications, so that I am not interrupted outside my working hours. |
| Priority | P2 (Nice to Have) |
| Estimate | 5 points |
| Sprint | Backlog |
| Dependencies | US-403 |
| Labels | Notifications, Settings |
Acceptance Criteria:
- Given I am on the notification settings page, When I enable quiet hours, Then I can set a start time and end time (e.g., 6:00 PM to 8:00 AM) and a timezone.
- Given quiet hours are active, When a notification triggers, Then in-app and Slack notifications are held and delivered when quiet hours end. Email notifications are delivered immediately (emails are asynchronous by nature).
- Given quiet hours are active, When I open the app during quiet hours, Then I see a banner: "Quiet hours active. Notifications will resume at [time]."
- Given a held notification exists, When quiet hours end, Then held notifications are delivered in a single batch (not individually) to avoid notification spam.
Story Mapping: How These Stories Connect
| Sprint 14 | Sprint 15 | Backlog |
|---|---|---|
| US-401: View settings (P0) | US-403: Channel selection (P1) | US-405: Quiet hours (P2) |
| US-402: Toggle categories (P0) | US-404: Admin defaults (P1) |
Epic summary. Sprint 14 delivers the core value: users can see and control their notifications. Sprint 15 adds channel flexibility and admin tools. Quiet hours go to backlog for a future sprint based on user demand.
Common Mistakes to Avoid
- Writing stories as technical tasks. "Create a notifications table in PostgreSQL" is a task, not a story. The user does not care about the database. Write the story from the user's perspective, then break it into tasks during sprint planning.
- Bundling multiple features into one story. "As a user, I want to view, edit, and share my notifications" is three stories. Split them. Each story should deliver one testable behavior.
- Vague acceptance criteria. "The page should be fast" is not testable. "The page loads in under 1 second at P95" is. Every acceptance criterion needs a specific, measurable condition that QA can verify.
- Skipping the benefit clause. "As a user, I want to set quiet hours" is incomplete. The benefit ("so that I am not interrupted outside my working hours") explains why this matters and helps the team make design tradeoffs.
- Writing stories in isolation. Stories exist within an epic. Map them to a story map (see above) so the team understands sequencing, dependencies, and the incremental value each sprint delivers.
Key Takeaways
- Every user story needs three parts: a specific role, a clear action, and a meaningful benefit
- Use Given/When/Then acceptance criteria to make stories testable by QA
- Run the INVEST checklist on every story before adding it to a sprint
- Split stories that cannot be completed in a single sprint using workflow, role, or business rule patterns
- Map connected stories to show sequencing and dependencies across sprints
About This Template
Created by: Tim Adair
Last Updated: 3/4/2026
Version: 1.0.0
License: Free for personal and commercial use