Both use cases and user stories describe what a system must do from a user's perspective. Yet they emerged from different traditions, are written at different altitudes, and serve different roles in a project. Understanding when to reach for each — and how to translate between them — is a core skill for any systems analyst.
Where They Come From
Use cases were formalised by Ivar Jacobson in the early 1990s as part of the Unified Process. They are structured documents that specify a primary actor, a goal, a main success scenario (step-by-step), and every meaningful alternate or exception path. They belong to the world of structured and object-oriented analysis.
User stories emerged from Extreme Programming (XP) around 1999 and were popularised by the Scrum framework. They are deliberately brief index-card-sized statements that defer detail to a conversation. They belong to the world of Agile delivery.
The Classic Formats
A use case is identified in a diagram (the ellipse labeled Book Appointment) and then documented in a structured template:
Use Case: Book Appointment
Actor: Patient
Preconditions: Patient is logged in; clinic has available slots.
Main Success Scenario:
1. Patient selects a specialty and preferred date.
2. System displays available doctors and time slots.
3. Patient selects a doctor and time slot.
4. System confirms the booking and sends a confirmation email.
Alternate Flow (A1 – No Slots Available):
2a. System displays "No slots available" and offers the next available date.
Exception Flow (E1 – Payment Failure):
4a. Payment gateway returns an error; system notifies patient and cancels the hold.
Postconditions: Appointment record created; doctor's calendar updated.
A user story follows the three-part card format:
As a Patient,
I want to book an appointment with a doctor online,
so that I can avoid waiting on the phone.
Acceptance Criteria:
- I can filter by specialty and date.
- I receive a confirmation email within 2 minutes.
- If no slot is available, I see the next available date.
Key structural difference: A use case is a document with preconditions, postconditions, and numbered flows. A user story is a conversation starter — the detail lives in the acceptance criteria and the team discussion, not on the card itself.
Comparison Table
Side-by-side comparison of use cases and user stories across six dimensions.
Granularity: Goals vs Tasks
A useful mental model is Alistair Cockburn's goal levels. User stories typically sit at the task or feature level — one story per sprint item. Use cases can span multiple goal levels: a single sea-level use case (Process Checkout) might decompose into several user stories (Add Item to Cart, Enter Shipping Address, Pay by Card).
A single sea-level use case (Process Checkout) decomposed into three user stories, each with acceptance criteria that correspond to the use case's alternate and exception flows.
When Each Approach Shines
Choose use cases when:
The project is safety-critical or regulated (medical devices, banking, aviation) and you need an auditable requirements baseline.
You are writing a fixed-price contract or a formal Request for Proposal and need precise, unambiguous scope.
The system has complex exception handling that must be enumerated (ATM error recovery, payment rollback).
You are generating test cases directly from requirements (see the next lesson).
Choose user stories when:
You are working in an Agile/Scrum environment with two-week sprints and a Product Owner driving prioritisation.
Requirements are evolving and you need to deliver value incrementally.
The team is small and co-located — conversation replaces documentation.
You want to keep the backlog lightweight and the focus on business value over specification completeness.
Hybrid approach — the sweet spot for most analysts: Write a use case diagram to establish the system boundary and actor/goal inventory. Then write user stories for each use case (or each scenario within a complex use case) to drive sprint planning. Acceptance criteria on the stories act as the use case alternate flows — captured just in time, not all at once.
Converting Between Them
Use case to user stories — a three-step recipe:
Take the main success scenario: each numbered step that delivers visible value to the actor becomes a candidate user story.
Promote significant alternate flows to their own stories (e.g., As a Patient, I want to join a waitlist when no slot is available).
Convert exception flows into acceptance criteria on the relevant story, or into a dedicated story if the exception handling is substantial.
User stories to use cases — cluster and elevate:
Group related stories by the goal they jointly achieve.
Name the cluster as a use case (the goal name).
Promote each story's acceptance criteria to alternate/exception flows in the use case narrative.
Identify the actor and draw the ellipse on the use case diagram.
Common mistake — writing use cases in user-story style: Some teams write "As a Patient, I want to book an appointment" on an index card and call it a use case. That is a user story. A use case requires the full structured template with pre/postconditions and numbered flows. Blurring the distinction degrades both artefacts.
Library System Example
Consider a library management system. A business analyst first draws a use case diagram and identifies Borrow Book as a sea-level use case. She then writes two artefacts:
-- USE CASE: Borrow Book --
Actor: Library Member
Precondition: Member is authenticated; book is available.
Main Success:
1. Member scans book barcode.
2. System checks member loan limit (max 5 books).
3. System records loan: member ID, book ID, due date (14 days).
4. System prints receipt.
Alt A: Loan limit reached → System displays warning; does not record loan.
Exception E1: Barcode unreadable → Prompt manual ISBN entry.
Postcondition: Loan record created; book status = On Loan.
-- USER STORIES (from the same goal) --
Story 1: As a Member, I want to scan a book barcode to borrow it,
so that checkout is fast.
AC: Scan takes < 2 seconds; receipt auto-prints.
Story 2: As a Member, I want to see a warning if I have reached
my 5-book limit, so that I understand why borrowing failed.
AC: Warning shown immediately; no partial loan created.
Notice that the exception flow E1 (unreadable barcode) does not warrant its own story — it is captured as an acceptance criterion on Story 1.
Summary
Use cases are structured documents that specify a complete goal including all flows; user stories are lightweight cards that defer detail to conversation.
Use cases excel in formal, contractual, or safety-critical contexts; user stories excel in Agile, evolutionary delivery.
One use case often maps to multiple user stories; acceptance criteria on stories carry the flow detail.
Many successful projects use a hybrid: use case diagrams for scope, user stories for sprint execution.