Agile

User Story Template

Standardize how you capture product requirements by focusing on user value and clear, testable acceptance criteria.

When to use this template

•When defining new features or updates during product discovery and backlog grooming.
•When communicating technical requirements to developers in a way that preserves business context.
•When establishing clear boundaries for what 'Done' looks like for a specific piece of work.

How to fill it in

1.Identify the specific persona (As a...) who will benefit from the change.
2.Describe the intent (I want to...) without prescribing a technical solution.
3.Articulate the value (So that...) to ensure the team understands the underlying motivation.
4.Define 3-5 Acceptance Criteria using the Given/When/Then format to make the story testable.

Template preview

Example User Stories

·As a frequent traveler, I want to filter search results by 'refundable' status, so that I can book with confidence.
·As a workspace admin, I want to invite team members via email, so that we can collaborate on projects.
·As a mobile user, I want biometric login, so that I can access my data securely without typing a password.

INVEST Checklist

·Independent: Can be delivered without relying on other pending stories.
·Negotiable: Details are refined through conversation, not set in stone.
·Valuable: Delivers a clear benefit to the end user or the business.
·Estimable: The team understands the scope well enough to weigh the effort.
·Small: The work is narrow enough to be completed within a single sprint.
·Testable: Success can be objectively verified through acceptance criteria.

Acceptance Criteria (BDD)

·Given: The user is on the 'Forgot Password' page.
·When: They enter a registered email address and click 'Submit'.
·Then: A recovery link is sent to that email address.
·Then: A success message is displayed on the UI.

Copy as Markdown

## Example User Stories
1. **As a** workspace admin, **I want to** invite new team members via email, **so that** they can collaborate on projects immediately.
2. **As a** billing manager, **I want to** download PDF invoices from the dashboard, **so that** I can reconcile monthly expenses for accounting.
3. **As a** mobile user, **I want to** enable biometric login, **so that** I can access my data securely without typing a password every time.

## User Story Template
**Title:** [Brief, descriptive title]

**User Story:**
**As a** [Type of user],
**I want to** [Perform an action],
**So that** [Value or benefit achieved].

**Acceptance Criteria:**
- [ ] [Criterion 1: Given... When... Then...]
- [ ] [Criterion 2: Given... When... Then...]
- [ ] [Criterion 3: Given... When... Then...]

**Notes/Mockups:**
- [Link to Figma, technical docs, or logic flows]

## Writing Good Acceptance Criteria
To ensure your stories are testable, use the BDD (Behavior Driven Development) format:
- **Given:** The initial context or state (e.g., 'the user is logged in').
- **When:** The action performed by the user (e.g., 'they click the delete button').
- **Then:** The expected outcome or visible change (e.g., 'the item is removed and a toast notification appears').

## INVEST Checklist
Before moving a story to 'Ready', ensure it meets these standards:
- **Independent:** Avoid tight coupling with other stories.
- **Negotiable:** Leave room for developer input on implementation.
- **Valuable:** If there is no value to a user or the business, don't build it.
- **Estimable:** Provide enough detail so the team can judge the effort.
- **Small:** If it takes more than one sprint, break it down into smaller stories.
- **Testable:** Every criterion must be verifiable by QA or automated tests.

---
Template provided by [Planet Roadmap](https://planetroadmap.com)

Draft your user stories in Planet Roadmap and instantly link them to OKRs or track them on a Kanban board to ensure every feature delivers measurable value.

Skip copy-paste. Set up this template inside a Planet Roadmap project in one click.

Try Planet Roadmap Free

FAQ

What is the difference between a user story and a task?

A user story describes a requirement from the perspective of the end user and focuses on the 'what' and 'why'. A task is a technical step (e.g., 'Create database schema') required to implement that story and focuses on the 'how'.

How small should a user story be?

Ideally, a user story should be small enough to be completed within a single sprint. If a story is too large to fit in an iteration, it is considered an 'Epic' and should be broken down into multiple smaller stories.

Who is responsible for writing user stories?

While the Product Manager or Product Owner typically owns the backlog, writing user stories is a collaborative process. Engineers and Designers should contribute to ensure the criteria are technically feasible and user-centric.

What if a story doesn't have a clear user value?

If a story is purely technical (like a refactor), it might be a 'Technical Spike' or 'Tech Debt' item. However, even these can often be phrased as a story (e.g., 'As a developer, I want to refactor the auth logic so that we can reduce login latency by 200ms').

Related templates