Use Case vs User Story: Key Differences

When to use each, how to write them well, and how they fit into Agile and traditional BA delivery. With worked examples of both.

The Core Difference

Both use cases and user stories describe what a system should do — but they do it at different levels of formality, detail, and collaboration.

A user story is intentionally brief: it captures the ‘who, what, and why’ of a requirement in a sentence, leaving the detail to be worked out through conversation between the BA, developer, and stakeholder. It’s designed for Agile teams that value working software over comprehensive documentation.

A use case is more comprehensive: it documents a specific interaction between an actor and a system, including the main success flow, alternative flows, error conditions, preconditions, and postconditions. It’s designed for environments where requirements need to be fully documented before development begins.

User Stories — In Depth

The Standard Format

The classic user story format: As a [user type], I want [capability], so that [benefit].

Example: As a registered customer, I want to save my delivery address so that I don’t have to re-enter it on every order.

What Makes a Good User Story

The INVEST criteria are the standard checklist for user story quality:

• Independent — can be developed and delivered without depending on another story being done first
• Negotiable — the story is a starting point for conversation, not a fixed specification
• Valuable — delivers real value to the user or business (weak: ‘As a developer, I want a database table…’; strong: ‘As a customer, I want…’)
• Estimable — the team can estimate the work involved; if they can’t, the story needs more refinement
• Small — deliverable within a single sprint; if it takes more than a sprint, split it
• Testable — acceptance criteria exist that define what ‘done’ looks like

Acceptance Criteria

Acceptance criteria define the conditions that must be true for the story to be accepted as complete. The most common format is Given/When/Then (Gherkin):

Given I am logged in as a registered customer
When I complete a purchase and tick ‘save this address’
Then my delivery address appears pre-filled on my next order

Each user story should have at least one acceptance criterion. Complex stories may have 4–8 scenarios covering the main flow and key edge cases.

Epics and Stories

Large features that can’t be delivered in a single sprint are called Epics. An Epic is broken down into multiple user stories that can each be independently delivered. Example Epic: ‘Customer address management’ → Stories: save address, edit address, delete address, select from saved addresses at checkout.

Use Cases — In Depth

Use Case Structure

A formal use case document typically includes:

• Use Case Name — a verb-noun description: ‘Place Order’, ‘Reset Password’, ‘Generate Report’
• Actor(s) — who initiates this use case (e.g. Registered Customer, Admin User, Payment Gateway)
• Preconditions — what must be true before this use case can begin
• Main Success Flow — the step-by-step sequence of actions when everything works as expected
• Alternative Flows — what happens when the main flow diverges (e.g. invalid input, system timeout, user cancels)
• Exception Flows — error conditions that end the use case without success
• Postconditions — what is true after the use case completes successfully
• Business Rules — constraints and rules that govern the interaction

Use Case Diagrams

A use case diagram (UML) provides a visual overview of all use cases in a system and the actors who interact with them. It shows scope and relationships without documenting the detail of each interaction.

Use case diagrams are useful for: communicating system scope to stakeholders, documenting the boundary between a system and external actors, and organising a large set of use cases into a comprehensible view. They’re less useful for specifying the detail of individual interactions — that’s what the use case narrative document is for.

When to Use Each

Use User Stories when:

• You’re working in an Agile/Scrum team
• Requirements will be elaborated through conversation and collaboration
• Work needs to be sprint-sized and prioritised in a backlog
• The team is co-located or has strong communication channels
• Speed of delivery is more important than comprehensive upfront documentation

Use Use Cases when:

• Working in a traditional delivery environment with formal requirements sign-off
• System interactions are complex with multiple alternative and exception flows
• Requirements documentation is required for compliance, audit, or contract purposes
• Development team works from detailed specifications rather than close collaboration
• Building systems with complex business rules that need to be precisely documented
• Integration with external systems requires formally specified interaction contracts

Using Both

Many mature BA practitioners use both in the same project — user stories for sprint backlog management, and use case narratives for complex business rules and integration specifications that don’t fit neatly into a story card. The key is knowing what level of detail each situation requires and matching your documentation approach to your delivery method.

Worked Examples

Same requirement as a User Story

As a registered customer, I want to reset my password via email so that I can regain access to my account if I forget my password.

Acceptance criteria:
Given I am on the login page
When I click ‘Forgot Password’ and enter my email address
Then I receive a password reset email within 2 minutes

Given I click the reset link in the email
When I enter a new password that meets the requirements
Then my password is updated and I am logged in

Same requirement as a Use Case

Use Case: Reset Password
Actor: Registered Customer
Preconditions: Customer has an existing account
Main Success Flow:
1. Customer clicks ‘Forgot Password’ on login page
2. System displays email entry form
3. Customer enters registered email address
4. System validates email and sends reset link (valid 60 minutes)
5. Customer clicks reset link
6. System validates link is active and not expired
7. Customer enters new password twice
8. System validates password meets requirements (8+ chars, 1 uppercase, 1 number)
9. System updates password and logs customer in

Alternative Flow — Email not found: At step 3, if email is not registered, system displays ‘If an account exists…’ message (security; does not confirm or deny registration)

Exception — Link expired: At step 6, if link is expired, system displays error and offers to re-send reset email

Frequently Asked Questions

Are use cases outdated?

Not outdated — but less universal than they once were. In Agile environments, user stories have largely replaced use cases for routine requirements management. But use cases remain the best tool for documenting complex system interactions, integration contracts, and compliance-sensitive processes where full documentation is required. Knowing both makes you a more versatile BA.

How many user stories make a use case?

There’s no fixed ratio, but a single use case often maps to 3–10 user stories when broken down for Agile delivery. The use case covers all flows (main, alternative, exception); each story covers a specific slice of that flow. Epic-level user stories often correspond to a single use case.

Can user stories replace use cases completely?

In pure Agile environments with high team collaboration, yes — user stories plus acceptance criteria cover most requirement documentation needs. In traditional delivery, compliance environments, or large system integrations, use cases still provide value that user stories can’t replace. The choice depends on your delivery method and documentation requirements.

Further reading: Agile Business Analysis Guide | Requirements Gathering Techniques | How to Write a BRD | 15 Essential BA Techniques