Use Cases vs User Stories: When to Pick Which

Contributor
Apr 11
5 min read

User stories and use cases are both ways to capture requirements from the user's perspective, but they're different artifacts with different strengths. User stories are short and conversational; use cases are detailed and structured. The choice between them depends on what you're trying to capture and how the team works.

User Stories

The format is small and conversational:

As a [role], I want [capability], so that [benefit].

Acceptance criteria:
- [Specific condition]

A typical user story fits on a card. The point is brevity and conversation. The story is a placeholder for a discussion, not a complete specification.

Strengths:

Quick to write
Approachable for non-technical stakeholders
Encourages iteration
Fits naturally with agile/incremental delivery

Weaknesses:

Lacks structure for complex interactions
Edge cases often missed
Easy to ship without enough detail
Doesn't capture system flows that span multiple steps

Use Cases

The format is detailed and structured:

Use Case: [Name]
Actor: [Who initiates]
Preconditions: [What must be true to start]
Main flow:
  1. [Step]
  2. [Step]
  ...
Alternate flows:
  - [Variation]
Postconditions: [What's true after]

A typical use case is a few pages, with the main flow plus alternates.

Strengths:

Captures complex interactions
Forces explicit alternate paths and error cases
Documents system behavior comprehensively
Useful for compliance and audit contexts

Weaknesses:

Heavier to write and maintain
Can become bureaucratic
Less iterative
Sometimes over-specifies, locking in solutions

When to Use User Stories

Agile development with frequent iteration
Small to medium features
Teams in close communication with stakeholders
Products where requirements evolve through use
Most modern web and mobile product development

User stories are the default for most agile teams. They balance brevity with enough structure to capture intent.

When to Use Use Cases

Complex multi-step interactions
Workflows with many alternate paths
Regulated environments requiring documented system behavior
Systems integration where flows span components
Replacing legacy systems where behavior must be preserved
Large-scale enterprise software

Use cases handle complexity that stories don't, at the cost of more writing.

Combining Both

You don't have to pick one.

A common pattern:

Write user stories for the day-to-day feature work
Write use cases for complex flows or critical scenarios
Use cases inform multiple user stories
Stories implement parts of use cases incrementally

The two complement: use cases describe the whole picture; stories slice it into deliverable increments.

A Side-by-Side Example

As a user story:

As a customer, I want to receive a refund for a returned item,
so that I'm not paying for something I don't have.

Acceptance criteria:
- Returns processed within 5 business days
- Refund to original payment method
- Confirmation email sent
- Order history reflects the refund

As a use case:

Use Case: Process Customer Return and Refund

Actor: Customer Support Agent
Preconditions:
- Customer has reported a returned item
- Item received at fulfillment center
- Item in returnable condition (per policy)

Main Flow:
1. Agent opens the order in CRM
2. Agent confirms item received in warehouse system
3. Agent verifies return reason against policy
4. Agent initiates refund
5. System charges refund to original payment method
6. System sends confirmation email to customer
7. System updates order status to "Refunded"
8. System logs the action with timestamp and agent ID

Alternate Flows:
A1. Item not in returnable condition:
  - Agent contacts customer to discuss
  - If approved, override required from supervisor
  - Otherwise, return rejected

A2. Refund to original payment method fails:
  - System creates store credit instead
  - Agent confirms with customer
  - Email reflects store credit not refund

A3. Customer no longer has the original payment method:
  - Agent requests alternative payment method
  - Customer provides; refund processed there
  - Confirmation email sent

Postconditions:
- Customer's account reflects the refund or store credit
- Inventory adjusted
- Financial records updated
- Audit log entry created

Same feature, different depth. The story is enough for the team to discuss and start work. The use case captures details that would otherwise emerge during implementation.

When User Stories Aren't Enough

Signs a story might warrant a use case:

Multiple system behaviors depending on conditions
Important alternate flows
External actor involvement (third-party integrations)
Complex post-conditions
Compliance audit requirements

When you find yourself writing 15 acceptance criteria to capture a story, you probably want a use case.

When Use Cases Are Overkill

Signs a use case is more than needed:

Single-step interaction
No meaningful alternates
Already-understood behavior
Iteration would invalidate the detail

Don't write use cases for everything. The maintenance cost is real.

Use Case Diagrams vs. Use Case Text

Use case diagrams (the UML circle-and-stick-figure style) are sometimes useful for overview. They show actors, use cases, and relationships at a glance.

The diagrams aren't the use cases. The text is. The diagram is a navigation aid.

For most teams, use case text matters; use case diagrams are optional.

Job Stories: A Variation

Job stories reframe user stories around situations and motivations:

When [situation], I want to [motivation], so that [expected outcome].

Example:

When my checkout fails because of an expired card, I want to be able to update the card without re-entering my order, so that I don't have to start over.

Job stories work well when the user's situation drives the requirement. They're less role-focused than classic user stories.

Use job stories as a complementary tool, not a replacement.

Avoid Solution-Shaped Stories

A common mistake in both formats: pre-specifying the solution.

Bad: "As a user, I want a dropdown menu in the header showing recent items..."

Better: "As a user, I want to quickly access items I recently viewed..."

The first locks in the UI. The second describes the need; the team designs the UI.

Granularity

Both stories and use cases have granularity questions.

For stories:

Each story should fit in a sprint (1-2 weeks)
Each story should deliver user value
Split stories that are too large by role, workflow step, data type, or platform

For use cases:

Each use case is one user goal
One use case = one complete interaction
Don't bundle unrelated flows into one use case

Maintaining Either

User stories typically don't outlive the sprint they're delivered in. Use cases live as long as the behavior they document.

For use cases:

Update when the actual system behavior changes
Mark deprecated use cases when functionality is removed
Keep alternate flows current as edge cases are discovered

Stale use cases are misleading. Treat them as living documents.

Anti-Patterns

Stories pretending to be use cases. Adding 30 acceptance criteria to a story to capture detail. If the detail is needed, write the use case.

Use cases for everything. Treating every small feature as a use case. Crushing weight of documentation.

Use cases describing implementation. "The system queries the database, then..." That's design, not requirements.

Stories without conversation. Written and thrown over the wall. Defeats the purpose.

Key Takeaway

User stories are short and conversational; use cases are detailed and structured. Stories fit agile iteration; use cases fit complex flows and regulated contexts. Use stories as the default for most product work; reach for use cases when the complexity warrants them. The two complement: use cases describe the whole interaction; stories slice it into deliverable increments. Match the artifact to the need, not to dogma about one being right.

ShiftQuality