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.