User story
A user story is a short, plain-language description of a piece of functionality, told from the perspective of the person who wants it. It is the most common form of a product backlog item in agile teams. The point of a story is not to specify the software in full. It’s to capture who wants what and why, and to be a promise for a conversation rather than a finished spec.
The usual template:
As a
<type of user>, I want<some goal>, so that<some benefit>.
Example
As a registered shopper, I want to save items to a wishlist, so that I can buy them later without searching again.
Also known as
story · (in tools) ticket · issue · card · work item. These tool names lump stories together with bugs and tasks
Don't confuse with
- Epic: a story too big for one Sprint; it gets split into several stories.
- Task: the technical to-dos a team breaks a story into (“add DB column,” “write endpoint”). Tasks are how; a story is what/why.
- Use case: an older, more formal and detailed description of every interaction step. A story is deliberately lighter.
- Requirement: a traditional spec states the system shall…. A story reframes the same need around a user and a reason.
The three parts (“the 3 C’s”)
Ron Jeffries described a story as three things, not just the sentence:
- Card: the short written story (the template above).
- Conversation: the discussion between the team and the customer that fleshes out the detail.
- Confirmation: the acceptance criteria that let everyone agree it’s done.
What makes a good story: INVEST
A widely used checklist (Bill Wake). A good story is:
- Independent: can be built on its own,
- Negotiable: not a rigid contract; details are discussed,
- Valuable: delivers value to a user or customer,
- Estimable: the team can size it,
- Small: fits within a sprint,
- Testable: you can confirm when it’s done.
Acceptance criteria
Each story carries acceptance criteria, the specific conditions it must satisfy. A popular format is Given / When / Then (from behavior-driven development):
Given I have items in my wishlist, when I click “move to cart,” then those items appear in my cart.
Acceptance criteria vs Definition of Done
Acceptance criteria are per-story (does this feature work as intended?). The Definition of Done is team-wide (is any work releasable: tested, reviewed, documented?). A story can pass its acceptance criteria yet still not be “done.”
Origin
User stories come from Extreme Programming (Kent Beck), which used them in place of heavy up-front requirements documents.
See also
References
- M. Cohn, User Stories Applied: For Agile Software Development, Addison-Wesley (2004). https://www.mountaingoatsoftware.com/books/user-stories-applied
- R. Jeffries, Essential XP: Card, Conversation, Confirmation (2001). https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/
- B. Wake, INVEST in Good Stories, and SMART Tasks (2003). https://xp123.com/invest-in-good-stories-and-smart-tasks/