User Story Templates
As a [user], I want [goal], so that [benefit] — and when a story is too large
User story format
- Template: As a [specific role], I want [specific goal], so that [business benefit]
- "So that" — clarifies value and guides design trade-offs; never omit it
- Epic — a story too large for one sprint; chains multiple goals with "and" or covers an entire flow
- Split patterns: by workflow step, user type, happy/unhappy path, business rule
- Technical tasks can use user stories too: "As a developer, I want… so that…"
Question 0 of 5
Which user story is written correctly using the standard template?
As a [user], I want [goal], so that [benefit] is the correct format. User story components:
- Who: "logged-in user" — specific role, not "user" alone
- What: "filter search results by date range" — the feature goal
- Why: "so that I can find recent articles more quickly" — the business benefit
The "so that" clause of a user story is sometimes omitted. Why is it important to include it?
Clarifies value and guides design trade-offs. How "so that" helps:
- Example: "As a free user, I want to export my data so that I can move to another service."
- The "so that" tells the team the user cares about data portability — they might accept CSV even if PDF is unavailable
- Without it: "I want to export my data" — the team may build only PDF export and miss the portability goal
Which user story is too large (an epic) and needs to be split?
Covers the entire onboarding flow — 5+ distinct features — this is an epic, not a story. Signs a user story is an epic:
- Uses "and", "or", "then" to chain multiple steps
- Describes an entire user journey rather than one specific action
- Would take more than one sprint to implement
- Cannot be tested with a single set of acceptance criteria
You need to write a user story for a technical task (adding database indexing). Which format is best?
Technical user stories use the developer/system as the "user". Technical story guidelines:
- The role can be "developer", "system", "data engineer", or even "monitoring"
- The goal should still describe the technical objective specifically
- The "so that" anchors it to a measurable outcome ("under 200ms")
A product owner says: "I want a user story for the entire payment system redesign." What is the correct response?
Identify as an epic and collaborate on splitting. How to split an epic:
- By workflow step: add card → process payment → confirm → receipt → refund
- By user type: guest checkout → registered user checkout → admin refund
- By happy/unhappy path: successful payment → payment declined → network failure
- By business rule: card payment → bank transfer → wallet payment