User Stories
A short, simple description of a software feature told from the perspective of the end user, capturing who needs it, what they need, and why.
What it is
User Stories follow the format "As a [type of user], I want [some goal], so that [some reason]." They are intentionally brief—details are added through conversation and acceptance criteria. A good story follows INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.
Unlike traditional requirements documents, user stories are conversation starters. They exist to capture the essence of a need without prescribing exactly how to build it. The team discusses the story, asks questions, and agrees on acceptance criteria before work begins.
When to use it
Use user stories for all product backlog items in agile teams. They work best when:
- The team is delivering software iteratively
- Stakeholders need to understand priorities without reading technical specs
- Requirements are expected to evolve as the team learns
- You need to split large initiatives into deliverable chunks
Benefits: user-centric focus, facilitates conversation, flexible to change, understandable by non-technical stakeholders.
Key concepts
The Format
The classic user story template has three parts:
| Component | Purpose | Example |
|---|---|---|
| As a | Identifies the user or role | As a registered customer |
| I want | States the goal or action | I want to reset my password |
| So that | Explains the benefit or motivation | So that I can regain access to my account |
INVEST Criteria
Bill Wake's INVEST mnemonic helps you write stories that are ready for development:
| Letter | Meaning | What it means in practice |
|---|---|---|
| I | Independent | Can be developed and delivered without heavy dependency on other stories |
| N | Negotiable | Open to discussion and refinement—not a fixed contract |
| V | Valuable | Delivers clear value to the user or business |
| E | Estimable | The team can size it with reasonable confidence |
| S | Small | Fits within a single sprint or iteration |
| T | Testable | Has clear acceptance criteria that can be verified |
Acceptance Criteria
Acceptance criteria turn a vague story into a testable deliverable. They describe the specific conditions that must be met for the story to be considered complete. A common format is Given-When-Then:
Given I am on the login page
When I enter a valid email and click "Forgot Password"
Then I should receive a reset link within 5 minutes
Story Splitting
When a story is too large, split it using one of these patterns:
- By workflow step — split across stages (e.g., draft, review, publish)
- By business rule — implement one rule at a time
- By data variation — handle one input type or edge case per story
- By happy vs. unhappy path — success case first, errors later
- By operation — CRUD operations as separate stories
Epics vs Stories
An epic is a large body of work that can be broken down into multiple stories. Epics often represent a feature or initiative that spans multiple sprints. Stories are the granular, sprint-sized pieces that deliver incremental value.
Common pitfalls
- Writing stories that are actually technical tasks. "Update the database schema" is not a user story—it has no user and no visible outcome.
- Making stories too large. If a story can't be completed in one sprint, split it.
- Including solution details. "As a user, I want a dropdown" prescribes UI instead of describing the need.
- Writing without understanding the user. Stories grounded in assumptions rather than research lead to the wrong features.
- Treating the format as a substitute for research. The template helps structure thinking, but it doesn't replace talking to real users.
NZ context
In NZ government and enterprise contexts, user stories bridge the gap between business stakeholders who think in outcomes and technical teams who think in implementation. Agencies like the Department of Internal Affairs and Ministry of Business, Innovation and Employment use story-based backlogs to align multi-vendor delivery teams with policy outcomes.
Local teams often face additional constraints: procurement cycles, ministerial reporting, and integration with legacy Crown systems. Well-written user stories help non-technical stakeholders understand what the team is building and why, without requiring them to read architecture diagrams.
The Service Innovation Lab approach and Digital Service Design Standard both emphasise starting with user needs—user stories are one of the most practical tools for doing that at sprint level.
Career level guidance
Graduate Tester
Learn the user story format and how to read acceptance criteria. Ask questions when stories are unclear before you start testing. Practise writing Given-When-Then scenarios for existing stories.
Junior Tester
Write acceptance criteria for stories during refinement. Identify when a story is missing edge cases or unclear scope. Start contributing to story splitting discussions with testability in mind.
Senior Tester
Facilitate story refinement sessions. Coach the team on INVEST and help rewrite stories that are too technical or too vague. Define test strategies that map back to story acceptance criteria across epics.
Test Lead
Set the team's story quality standards and definition of ready. Review stories before sprint planning to ensure they are testable, valuable, and appropriately sized. Mentor testers on story-writing and acceptance criteria practices.