# Consistency of User Story and Use Case **In short:** A user story and a use case describe one goal at different levels of detail. Keep them consistent so they never contradict each other. Treat the story as the brief, early form. ## Explanation A user story is a short statement of a need. A common template names a role, a feature, and a benefit. The role is who wants it. The feature is what they want. The benefit is why. Acceptance criteria go with the story. They help the team judge whether the story was completed correctly. A story can also be read in three parts: a brief card, a conversation that builds understanding, and a confirmation that tells the team when the story is complete (see the article Card, Conversation, Confirmation). A use case is more detailed. It can carry a goal level, which tells readers how detailed it is. For API and service design, aim at the user goal or subfunction level. The primary actor is the user from whose perspective the use case is written, and who starts it. Templates also list preconditions, which say what must hold before the use case can run. Postconditions describe what changes in the system afterward (see Use Case Template and Use Case Goal Level). **How the parts line up** - The story's role points to the use case's primary actor. - The story's feature points to the use case's goal. - The story's benefit relates to the postcondition, but they are not the same. A benefit states business impact. It should not formally specify a postcondition. - Acceptance criteria are a natural source for the conditions a use case spells out. The Design Practice Repository points to Given-When-Then, from behavior-driven development, as a template for criteria. Treat this mapping as a guide. Stories and use cases have no simple one-to-one mapping. **How they work together** Stories are a preliminary stage to use cases, not a direct alternative. You can derive use cases from early stories. Keep use cases short and readable. They should not take weeks of upfront documentation before development starts. ## Example A story reads: "As a customer, I can cancel an order, so that I avoid paying for goods I no longer want." Its criteria say what counts as done. The matching use case names the customer as primary actor and "Cancel order" as the goal. Its precondition says the order exists. Its postcondition says the order is marked canceled. If the story later changes, the use case must change with it, or the two will disagree. ## Trade-offs Keeping two artifacts consistent costs effort. Each change to one needs a check of the other. The mapping is not one-to-one, so some judgment is needed. Writing use cases too early or too thoroughly also adds cost. The facts here give no method for tracking changes, so teams must set their own habit. ## Checks - Each story's role matches the primary actor of its use case. - Story benefits state business impact and are not written as formal postconditions. - Use cases carry a goal level, aimed at user goal or subfunction for API and service design. - Use cases list preconditions and postconditions that do not contradict the story's acceptance criteria. ## Related - [User Story](https://arc.fuet.ch/concepts/functional-requirements/user-story.md) - [Use Case](https://arc.fuet.ch/concepts/functional-requirements/use-case.md) - [User Stories vs. Use Cases](https://arc.fuet.ch/concepts/functional-requirements/user-story-vs-use-case.md) - [Use Case Template](https://arc.fuet.ch/concepts/functional-requirements/use-case-template.md) - [Use Case Goal Level](https://arc.fuet.ch/concepts/functional-requirements/use-case-goal-levels.md) - [Acceptance Criterion](https://arc.fuet.ch/concepts/functional-requirements/acceptance-criteria.md) - [Card, Conversation, Confirmation](https://arc.fuet.ch/concepts/functional-requirements/card-conversation-confirmation.md) - [Traceability](https://arc.fuet.ch/concepts/principles/traceability.md) ## Sources - [design-practice-repository | Summaries of artifacts, templates, practices, and techniques for agile architecting (DPR-mm) and service design (SDPR-nn).](https://socadk.github.io/design-practice-repository/artifact-templates/DPR-UseCase.html) — socadk.github.io, accessed 2026-11-09 - [design-practice-repository | Summaries of artifacts, templates, practices, and techniques for agile architecting (DPR-mm) and service design (SDPR-nn).](https://socadk.github.io/design-practice-repository/artifact-templates/DPR-UserStory.html) — socadk.github.io, 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 - [Use Case](https://martinfowler.com/bliki/UseCase.html) — martinfowler.com, accessed 2026-11-09