User Story
A user story is a short description of a capability, written from the point of view of the person who wants it. The common template is "As a [role], I want [action], so that [benefit]." It captures who needs something and why, leaves the implementation to the team, and is paired with acceptance criteria that define when it is done.
How User Stories Work
User stories come from Extreme Programming (XP) and were popularized in Scrum by Mike Cohn, who defines one as a short description of desired functionality told from the perspective of someone who wants or needs it. A story names a single role, so its value and its tests stay focused.
Ron Jeffries described stories through three Cs:
- Card: a few words that identify the requirement. The card is a token, not the full specification.
- Conversation: the details are worked out in discussion between the people who need the capability and the people who build it.
- Confirmation: the tests that show the story works, today written as acceptance criteria.
Good stories are small enough to build and validate within a sprint. The INVEST checklist (Independent, Negotiable, Valuable, Estimable, Small, Testable) is a common quality test. A story too large to finish in one iteration is an epic and should be split before work starts. Teams often arrange stories along the user's journey in a user story map to see how they fit together.
Why User Stories Matter
Stories keep the user and the outcome at the center of the work. The "so that" clause gives developers the reason behind a request, which helps them make sensible decisions when details change. Small stories also shorten feedback loops: a team can ship one, learn from it and adjust the next.
Because a story describes intent rather than a solution, it invites the team to propose better ways of meeting the need. The acceptance criteria then make that intent testable, so "done" is not a matter of opinion.
Stories with clear scope and criteria are also good units of work for AI coding agents, which perform best on bounded, verifiable tasks. For that workflow, see how to generate agent-ready user stories from structured requirements.
User Story Example
"As a freelance designer, I want to see my overdue invoices on the dashboard, so that I can follow up before my cash runs short."
Acceptance criteria:
- Given I have invoices past their due date, when I open the dashboard, then they appear in an Overdue section sorted by days overdue.
- Given no invoices are overdue, when I open the dashboard, then the section shows "Nothing overdue".
- Given I mark an overdue invoice as paid, when the dashboard refreshes, then it leaves the Overdue section.
The story says nothing about database queries or layout. Those choices belong to the team.