Form Factory’s guide to writing user stories — from personas through to acceptance criteria. The process uses three complementary frameworks (3Ws, INVEST, 3Cs) and a five-step writing workflow. Stories are the primary unit of work; enablers handle research and technical prerequisites that don’t fit the story format. See placeholder-development for how to unblock stories when parts are incomplete.
Frameworks
3Ws
Every story answers: Who is it for? What do they do? Why do they need it?
INVEST
| Letter | Meaning | Key idea |
|---|---|---|
| I | Independent | No dependency on other stories |
| N | Negotiable | Essence, not a fixed contract |
| V | Valuable | Clear customer/user value |
| E | Estimable | Enough info to estimate (see story-point-matrix) |
| S | Small | Fits in a sprint (see story-point-matrix) |
| T | Testable | Tests can be defined |
3Cs Model
- Card — “As a «role», I want to «action», so that «benefit»”
- Conversation — stories are built through ongoing conversation; notes are memory aids, not replacements
- Confirmation — acceptance criteria verify the story is correctly implemented
Writing Process
- Describe personas — profile, activities, needs, goals
- Describe features — interactions of personas with the product
- Identify PBIs — break features into smaller backlog items (each = a user action)
- Connect as a User Story — fill the As a / I want to / So that template
- Fill out details — acceptance criteria, tasks, UI references, enablers
For a complete worked example of this process, see product-backlog-example.
Acceptance Criteria
Describe how to validate a story. Use Given/When/Then scenarios. Must be defined before implementation begins.
Enablers
Work items that don’t fit the user story format. Two types:
| Type | Purpose | Example |
|---|---|---|
| Exploratory (spike) | Research, clarification, choosing between options | ”Research async messaging approaches” |
| Technical | Infra, refactoring, non-functional requirements | ”Perform automated test migration” |
Enablers don’t need story format — use direct language. Always indicate which stories depend on them. Avoid an enabler-only backlog.
Epics
An epic is simply a large user story — no magic threshold. Calling something an epic signals it’s too big for a single sprint and needs further refinement. Stories are grouped into user-story-themes (e.g., Feature, DevOps, Security).
Definition of Ready (DoR)
A PBI is ready for a sprint when the team:
- Has the necessary information
- Understands the reason for the item
- Can demonstrate completion
- Knows how it relates to a feature
- Agrees it fits in a sprint
Definition of Done (DoD)
The team’s quality agreement for what “done” means. A PBI that doesn’t meet DoD stays as WIP — it cannot be released or shown in Sprint Review.