What is a user story?
A user story is a short, plain-language description of a feature from the user's perspective. The standard format is:
As a [role], I want [goal] so that [reason].
Example: "As a sprint planner, I want to see remaining capacity so that I don't over-commit the team."
The 3 Cs
Ron Jeffries' classic framing:
- Card — the user story is a placeholder, not a spec. Short enough to fit on an index card.
- Conversation — the real spec is the conversation between the team, PM, and stakeholders.
- Confirmation — the acceptance criteria that prove the story is done.
INVEST: what makes a story good
- Independent — can be shipped on its own
- Negotiable — scope can be discussed
- Valuable — delivers something the user notices
- Estimable — small enough to size
- Small — fits in a single sprint
- Testable — has clear acceptance criteria
Common user story mistakes
- "As a developer, I want..." — that's a task, not a user story. Stories are about end users.
- Too big — if it can't ship in a sprint, split it.
- No acceptance criteria — the team will guess what "done" means and guess wrong.
- Treating the format as gospel — the format is a starting point, not a religion. If your team understands the work without it, that's fine.