A user story is a short description of a feature from the perspective of the person who needs it. Done well, user stories give the delivery team clear, testable, and value-connected work items. Done poorly, they become ambiguous request statements that generate more questions than they answer.
- The standard format is a starting point, not a constraint
- Acceptance criteria are more important than the story format
- Stories should be small enough to complete in one sprint
- Epics are placeholders, not deliverables
The standard user story format
As a [user type], I want to [action], so that [outcome]. The format is a communication tool, not a requirement. The value is in forcing the author to name who the user is, what they want to do, and why it matters. If you cannot complete the third clause — the so that — the story is not connected to a business outcome and should not be in the backlog.
Acceptance criteria: the most important part
Acceptance criteria define when the story is done. They are specific, testable conditions that must be true before the story can be accepted. Each acceptance criterion should be independently testable. Acceptance criteria without clear criteria are requests; with clear criteria, they are commitments. Every story delivered to a sprint should have acceptance criteria agreed before sprint planning begins.
INVEST: the quality criteria for user stories
Independent: stories should be deliverable without depending on another story being done first. Negotiable: stories are not contracts; they invite conversation. Valuable: every story delivers value to a user or the business. Estimable: the team can estimate the work. Small: small enough to complete in one sprint. Testable: acceptance criteria can be verified.
Epics and story splitting
An epic is a large user story that is too big to deliver in one sprint. Epics are placeholders in the backlog that get split into stories before the team is ready to execute them. A common failure mode is delivering epics into sprints without splitting them, which means the sprint goal is too large and most stories will not be completed.
Common mistakes in user story writing
Writing stories from a system perspective instead of a user perspective. Missing the so that clause, which disconnects the story from value. Writing acceptance criteria that are too vague to test. Making stories too large to complete in one sprint. Skipping story refinement, which means the team has questions they cannot answer during sprint planning.
Frequently asked questions
User stories are most associated with Scrum and XP. Kanban teams often use them. Some organizations use alternative formats like job stories or use cases. The format matters less than having clear, testable, value-connected work items.
The Product Owner typically writes or owns stories, with input from the business analyst, Scrum Master, and development team. The development team should refine stories during backlog grooming before they enter a sprint.
Stories at the top of the backlog, scheduled for the next sprint, should be fully detailed with acceptance criteria. Stories further down can be high-level until they are closer to execution.
Request How to Write Good User Stories (With Examples)
Answer a few quick questions. We will recommend the right engagement and follow up within one business day.
Ready to put this into practice?
PMOstart provides consulting, fractional PMO leadership, templates, and tools to help you apply what you just read.