# User Story

**In short:** A user story is a short requirement written from a stakeholder's point of view. It is a reminder to talk, not a full specification. Details follow through conversation and acceptance tests.

## Explanation

A user story is a brief statement of something a stakeholder needs. It is not a detailed specification. One well-known description names three elements: Card, Conversation and Confirmation (see the article Card, Conversation, Confirmation).

**Card.** The card is only a token that stands for the requirement. It does not hold all the information the requirement needs.

**Conversation.** The details come out when people talk. The talk is mostly verbal, but documents can supplement it. Talking also exposes ambiguity that stays hidden in written text.

**Confirmation.** The customer defines acceptance tests. They show that the story has been implemented correctly (see Acceptance Criterion).

**The template.** A common form is: "As a [type of user], I [need/want/am required] to [do something], so that [reason or benefit]." It names who, what and why. Stakeholders find it natural, and it helps the product owner prioritize. It should not become a ritual. It is useful only while it improves the conversation.

**What a good story looks like.** The INVEST checklist (see INVEST Criteria) says a story must be valuable to the customer, not just to anybody. It is negotiable, so it captures the essence and not the details. It is estimable enough that the team can rank and schedule it.

**Why teams use stories.**
- They are usually easier to estimate and prioritize than use cases or long lists of requirement statements. This suits projects with limited time.
- They let teams defer detail until the detail is useful.
- Use cases describe generalized interactions and are often too large to estimate (see User Stories vs. Use Cases).

**Planning.** Extreme Programming has release planning and iteration planning. In both, the customer presents features. In iteration planning, programmers break them into tasks and estimate the cost at a finer level of detail than in release planning.

## Example

A online shop team writes this card: "As a shopper, I want to save items for later, so that I can buy them when I get paid."

The card says nothing about buttons or storage. The team talks with the customer. They ask whether saved items expire and how many can be saved. The customer then writes an acceptance test: a saved item is still there at the next visit. The team can estimate the story and rank it against others.

## Trade-offs

Stories keep requirements short and push detail into conversation. This exposes misunderstandings early and avoids writing detail that is never used. The cost is that the card alone is incomplete. Anyone who reads only the card lacks the details. Those details live in conversations, in supporting documents and in the acceptance tests. The template also helps only while it supports the conversation. Used as a ritual, it adds nothing.

The three elements of a user story: card, conversation and confirmation.

```mermaid
flowchart LR
  A[Card: short story] --> B[Conversation: details emerge]
  B --> C[Confirmation: acceptance tests]
  C -.-> B
```

## Checks

- Each story names a type of user, a goal and a reason or benefit.
- Stories are small enough to estimate and rank, and they capture the essence rather than every detail.
- Each story has customer-defined acceptance tests that show it was implemented correctly.
- The document states where story details live, such as conversations or supporting documents, since the card holds only part of the requirement.
- Each story is valuable to the customer, not only to some other party.

## Related

- [Card, Conversation, Confirmation](https://arc.fuet.ch/concepts/functional-requirements/card-conversation-confirmation.md)
- [INVEST Criteria](https://arc.fuet.ch/concepts/functional-requirements/invest-criteria.md)
- [Acceptance Criterion](https://arc.fuet.ch/concepts/functional-requirements/acceptance-criteria.md)
- [User Stories vs. Use Cases](https://arc.fuet.ch/concepts/functional-requirements/user-story-vs-use-case.md)
- [Use Case](https://arc.fuet.ch/concepts/functional-requirements/use-case.md)
- [Story Splitting](https://arc.fuet.ch/concepts/functional-requirements/story-splitting.md)
- [Epic](https://arc.fuet.ch/concepts/functional-requirements/epic.md)
- [Story Mapping](https://arc.fuet.ch/concepts/functional-requirements/story-mapping.md)

## Sources

- [Essential XP: Card, Conversation, Confirmation](https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/) — ronjeffries.com, accessed 2026-11-09
- [User Stories: What They Are, How to Write Them, and Examples - Mountain Goat Software](https://www.mountaingoatsoftware.com/agile/user-stories) — mountaingoatsoftware.com, accessed 2026-11-09
- [User Story Template: What It Is and Why It Works So Well - Mountain Goat Software](https://www.mountaingoatsoftware.com/agile/why-the-three-part-user-story-template-works-so-well) — mountaingoatsoftware.com, accessed 2026-11-09
- [Advantages of User Stories over Requirements and Use Cases - Mountain Goat Software](https://www.mountaingoatsoftware.com/agile/advantages-of-user-stories-for-requirements) — mountaingoatsoftware.com, accessed 2026-11-09
- [INVEST in Good Stories, and SMART Tasks - XP123](https://xp123.com/invest-in-good-stories-and-smart-tasks/) — xp123.com, accessed 2026-11-09
- [What is Extreme Programming?](https://ronjeffries.com/xprog/what-is-extreme-programming/) — ronjeffries.com, accessed 2026-11-09