Use Case vs User Story in Agile: Key Differences, Examples and Templates

A user story is a short statement of who wants something and why, written as a placeholder for a conversation. A use case is a structured description of how a user and the system interact step by step, including what happens when things go wrong. User stories replaced use cases for most day to day agile work, and the two combine usefully more often than the comparison suggests.

Key Highlights

• Use cases were created by Ivar Jacobson for requirements analysis and became a core part of UML.
• User stories emerged partly as a reaction to use cases being seen as heavy and slow to produce.
• A user story captures intent. A use case captures a flow, including alternative and exception paths.
• Stories are work items sized for a Sprint. Use cases describe a complete scenario that may span several stories.
• The most useful arrangement is often both: a use case as reference for a complex flow, stories as the work.
• Neither is a specification. Both are inputs to a conversation, and use cases simply hold more detail.

What Each One Is

The definitions matter here because the two are frequently described as alternatives when they are different kinds of artefact.

What is a use case?

A use case is a structured description of how an actor, such as a customer or another system, interacts with a system to reach a goal. It lists preconditions, the main step-by-step flow, alternative and exception flows, and postconditions, so the team can see what happens when things go wrong as well as when they go right.

Ivar Jacobson introduced the idea in the 1980s as part of Object-Oriented Software Engineering, and use cases later became a core element of the Unified Modeling Language (UML).

What is a user story?

A user story is a short statement of who wants something, what they want and why, usually written as: As a [type of user], I want [goal], so that [benefit]. It is a placeholder for a conversation, not a specification. The detail is agreed in discussion and captured as acceptance criteria.

User stories grew out of Extreme Programming, where Kent Beck and Ron Jeffries were early advocates, and Mike Cohn later popularized them among Scrum teams. A story is often described through the 3Cs: the Card (a short reminder), the Conversation (where the detail emerges) and the Confirmation (the acceptance criteria that show it is done).

Detail lives in the conversation and in acceptance criteria, which our guide to user story templates and examples covers with worked examples.

User stories emerged in part as a reaction to use cases. Teams found use cases time consuming to produce and heavy to maintain, and wanted a lighter way to hold requirements that could change quickly.

If you are working through the agile side of this, our free CSM practice test takes a few minutes.

Side by Side

The row that explains most of the others is the last but one. A user story is cheap to change because there is almost nothing to change. A use case with eleven steps and four alternative flows represents real effort, which makes people reluctant to alter it, which is exactly the dynamic agile methods were trying to escape.

The Same Requirement, Both Ways

Concrete makes the difference obvious.

As a user story.

As a returning customer, I want to reset my password so that I can get back into my account without contacting support.

With acceptance criteria: given I am on the sign in page, when I request a reset and enter a registered email, then a reset link is sent. Given the email is not registered, when I request a reset, then I see the same confirmation message rather than being told the account does not exist.

As a use case.

Actor: registered customer. Precondition: the customer has an account and access to their registered email. Main flow: the customer selects forgotten password, enters their email address, the system validates the address exists, generates a time limited token, sends an email containing a reset link, the customer follows the link, the system validates the token, the customer enters a new password, the system validates it against the password policy, updates the credential, invalidates the token and confirms.

Alternative flow: the email is not registered, and the system displays the same confirmation without sending anything. Exception flow: the token has expired, and the system offers to send a new link. Postcondition: the credential is updated and all existing sessions are invalidated.

Both describe the same feature. The story fits on a card and assumes a conversation will fill the gaps. The use case answers questions the story leaves open, including several the team might not have thought to ask.

Neither is better in the abstract. The story is faster to write and adapt. The use case surfaces the token expiry and session invalidation questions before anyone builds anything.

Three Paired Examples

Example 1: ATM cash withdrawal

Use case. Actor: account holder. Precondition: valid card and the ATM holds cash. Main flow: the holder inserts the card and enters the PIN; the system verifies it; the holder chooses an amount; the system checks the balance and the cash available, dispenses the cash, offers a receipt and returns the card. Alternative flow: the PIN is wrong, so the system allows a limited number of retries. Exception flows: the balance is too low, so the system offers a smaller amount; the ATM cannot reach the bank, so it cancels the transaction with no debit. Postcondition: the account is debited only if cash was dispensed.

User story. As an account holder, I want to withdraw cash at an ATM, so that I can pay for things without visiting a branch.

• Given my balance covers the amount, when I confirm it, then the cash is dispensed and my balance falls by the same amount.
• Given my balance is too low, when I request an amount, then I am told and offered a smaller amount.

Takeaway. The story is easy to prioritize; the use case is what reveals the network-failure and no-debit rule that testers need.

Example 2: Book a doctor appointment

Use case. Actor: patient. Precondition: the patient is registered and signed in. Main flow: the patient chooses a doctor, views free slots, picks one, confirms, and the system books it, updates the doctor's schedule and sends a confirmation. Alternative flow: the slot is taken between selection and confirmation, so the system shows the next available times. Exception flow: the patient leaves before confirming, so nothing is booked. Postcondition: one booking exists and a confirmation has been sent.

User story. As a patient, I want to book an appointment online, so that I do not have to phone the clinic during opening hours.

• Given a slot is free, when I confirm it, then it is booked and I receive a confirmation.
• Given two patients pick the same slot, when the second confirms, then they are offered other times and no double booking occurs.

Example 3: Return an online order

Use case. Actor: customer. Precondition: the order was delivered and is inside the return window. Main flow: the customer chooses the item and a reason; the system checks eligibility and issues a prepaid label; the customer ships the item; the warehouse inspects it; the system issues the refund. Alternative flow: the return window has passed, so the system explains why and declines. Exception flow: the item arrives damaged, so customer service asks for photos before refunding. Postcondition: a refund is issued or a reason for refusal is recorded.

User story. As a customer, I want to return an item and get a refund, so that I can buy with confidence.

• Given an eligible item, when I request a return, then I receive a prepaid label.
• Given the return window has passed, when I request a return, then I see why it cannot go ahead.

Use Case and User Story Templates

Use case template

User story template

How to Write Each One

How to write a use case

1. Name the actor. Pick one primary actor. Actors can be people or other systems, such as a payment gateway.

2. State the goal. Write what the actor wants to achieve, not what the system does internally.

3. List preconditions. Record what must already be true, such as being signed in.

4. Write the main flow. Number the steps from trigger to success, alternating actor actions and system responses.

5. Add alternative and exception flows. For each step ask what else could happen and what happens if it fails.

6. Define postconditions. State what is true when the use case ends, both on success and on failure.

How to write a user story

1. Identify the user. Name a real role or persona rather than "user".

2. Describe the goal. Keep it to one thing the user wants to do.

3. Explain the benefit. The "so that" clause tells the team how to prioritize.

4. Add acceptance criteria. Cover the main path and the realistic failure cases, usually two to five criteria.

5. Refine through conversation. Talk it through with the team and split the story if it will not fit in one Sprint.

What Is a Use Case Diagram?

A use case diagram is a UML picture that shows who uses a system and what they can do with it. It is a map of scope, not a description of steps, so it works alongside the written use case rather than replacing it.

• Actor: a person or external system that interacts with the system, drawn as a stick figure or labeled box.
• Use case: one goal the system supports, drawn as an oval with a verb phrase such as Reset password.
• System boundary: a rectangle around the use cases that belong to the system.
• Association: a line connecting an actor to a use case it takes part in.
• Include: a use case that always calls another one, such as Reset password including Validate password policy.
• Extend: an optional behavior that happens only under a condition, such as Send a new link extending Reset password when the token has expired.

For the password reset example the diagram has two actors (Registered customer and Email service), three main use cases (Request reset link, Complete reset, Send new link), and the include and extend relationships described above.

When Each Works Better

User stories suit work that is small, changes often, and where the team can talk to someone who knows what is wanted. Most feature development on a product with an available Product Owner falls here.

Use cases suit complex flows with many branches, regulated contexts where the interaction must be documented, integrations where the exact sequence matters, and situations where the people who understand the requirement are not available for daily conversation.

The condition that decides it is usually availability. User stories work because a conversation fills the detail. Where that conversation cannot happen, because the expert is in another organisation or another time zone, the detail has to live somewhere, and a use case is where.

Three specific situations where use cases still earn their place.

Regulated or safety critical work. Documented interaction flows are frequently required, and the documentation exists for audit rather than for the team.

Complex state machines. A booking flow with twelve states and rules about which transitions are permitted is genuinely hard to hold in stories alone.

Vendor or contract boundaries. When another party is building to your specification, precision protects both sides in a way a conversation cannot.

Using Both Together

The arrangement most comparisons omit, and often the practical answer.

Some teams write a use case to capture the full flow of a critical scenario, then break it into user stories for delivery. The use case becomes the reference document and the stories become the work items.

This works well because each artefact does what it is good at. The use case holds the complete picture, including the exception paths that are easy to forget. The stories are sized for a Sprint, ordered independently, and cheap to reprioritise.

The password reset example above splits naturally: request a reset link, complete a reset, handle an expired token, invalidate existing sessions. Four stories, one reference describing how they fit together.

Two cautions if you do this.

Keep the use case at scenario level. Writing one per story recreates the heaviness without the benefit.

Decide which is authoritative. When the use case and the acceptance criteria disagree, someone has to know which wins. Usually the acceptance criteria, since they are closer to the work, and the use case then needs updating or accepting as stale.

The split into deliverable pieces is the same skill as splitting any large item, covered in our guide to epic versus user story, and the ordering that follows is in our guide to prioritising user stories.

How Use Cases and User Stories Feed Testing

Both artefacts become tests, but at different levels. Acceptance criteria on a user story turn directly into acceptance tests that show the story is done. A use case goes further: the main flow becomes the happy-path test, and every alternative and exception flow becomes a negative or edge-case test. That is why use cases are valued for integration and user acceptance testing on complex flows, and why a team that drops them should keep asking what happens when each step fails.

In the password reset example, the main flow gives one end-to-end test, the unregistered email flow gives a test that no account information leaks, the expired token flow gives a test for the new-link offer, and the postcondition gives a test that old sessions are ended.

How Do Use Cases and User Stories Fit into Scrum and Kanban?

In Scrum, user stories are Product Backlog items. The team refines them, and the Product Owner orders them for Sprint Planning. The Scrum Guide does not prescribe a format, so a use case can sit beside the backlog as a reference for a complex flow, with each story linking to the relevant steps. In Kanban, stories flow across the board as capacity allows. Work-in-progress limits push teams toward small stories, which makes it practical to split one use case into several cards and reference it on each.

Where Do Story Maps Fit?

A story map lays user stories out along the user's journey so the team can see the whole flow and slice releases from it. It restores the complete picture that individual stories lose, which is the same problem a use case solves with detail. Many teams use a story map for the overview and a use case only for the few flows that need precision.

What Stories Lose

An honest account, since the agile literature tends to present the replacement as pure gain.

Exception paths get forgotten. A use case forces you to enumerate what happens when things fail. Stories rely on someone thinking to ask, and under time pressure nobody does. This is the most common cause of work returning after it was called finished.

The complete picture disappears. Forty stories describe a system in fragments. Nobody can read them and understand how the whole thing behaves, which matters when someone new joins or when a change touches several areas.

Sequence becomes implicit. Use cases show order explicitly. Stories are independent by design, so the order in which things must happen has to be captured somewhere else or held in people's heads.

Institutional memory weakens. A conversation is not a record. Teams with high turnover lose the reasoning behind decisions faster with stories than with documents.

None of these argues for returning to use cases as the default. They are the costs of the trade, and teams that recognise them can mitigate each: deliberately asking about failure paths in refinement, keeping a lightweight system overview, and writing down decisions that were expensive to reach.

Recognising that a practice has costs as well as benefits is a normal part of the Scrum Master's judgement, and it is covered directly in CSM Certification Training.

Common Mistakes

Writing a use case as a user story. A three page item in the as a, I want to format is a use case wearing a costume, and it will not fit in a Sprint.

Treating a story as a specification. The card is a placeholder. Teams that try to make it carry the full detail end up with the length of a use case and none of its structure.

Abandoning exception thinking. The most damaging consequence of dropping use cases. Ask what happens when this fails, every time, in refinement.

Maintaining both fully. Duplicated detail in two places goes out of sync within weeks. Pick which is authoritative.

Using use cases because they feel more rigorous. Length is not rigour. A precise story with testable acceptance criteria is more useful than a vague use case with eleven steps.

Choosing for Your Own Team

Four questions that settle it without a debate.

Can the team talk to someone who knows what is wanted? If yes, stories work, because the conversation supplies the detail. If no, the detail has to be written down and a use case is the structure for it.

How complex is the flow? A linear interaction with two outcomes suits a story. Twelve states with rules about permitted transitions needs something that can hold that.

Does anything require the interaction to be documented? Regulatory obligations, audit requirements or a contract with another party all push toward use cases regardless of preference.

Who will read it, and when? A story is read by the team this Sprint. A use case is read by someone in eighteen months trying to understand how the system behaves. If the second reader exists, something more durable than a card is needed.

Most teams answer yes, simple, no, and only the team, which is why stories dominate. Teams that answer differently on any one of them should not feel they are doing agile incorrectly by writing more down.

The mistake worth avoiding is deciding once and applying it everywhere. A product with one genuinely complex flow and thirty straightforward features benefits from a use case for the first and stories for the rest. Uniformity is not a virtue here.

What Both Have in Common

Easy to lose in a comparison, and worth stating.

Neither is the requirement. Both are representations of something someone wants, and both are wrong in some detail that will only surface when working software exists. Treating either as authoritative and complete is the error, and it is available in both formats.

Both also depend on the same underlying skill: understanding what the user is actually trying to achieve. A badly written use case and a badly written story fail identically, because the failure is upstream of the format. Someone who has not understood the need produces eleven precise steps toward the wrong outcome just as easily as a vague card.

That is the argument for spending time on the conversation rather than the artefact. Refinement, where the team asks questions and the item improves, is where both formats get their value, and it is covered in our guide to backlog refinement.

What Business Analysts Should Know

A note for anyone arriving from a requirements background, since this comparison lands hardest there.

The shift is not from precision to vagueness, which is how it frequently feels. It is from documenting a requirement completely to ensuring a conversation happens at the right moment. Both aim at the same outcome; they distribute the effort differently.

Three things that transfer directly.

Asking what happens when it fails. The single most valuable habit from use case work, and the thing agile teams most often lose. Bringing it into refinement recovers most of what the format provided.

Understanding actors and their goals. A story with as a user in it says nothing. Someone trained to think about distinct actor types writes considerably better stories than someone who was not.

Spotting missing preconditions. What has to be true before this can happen is a use case question that improves any story it is asked of.

What does not transfer is the documentation itself as a deliverable. The value moves from the artefact to the questioning, which for people whose expertise was demonstrated through documents is a genuine adjustment in how contribution is recognised.

The compensation is influence. A business analyst asking the right question in refinement changes what gets built, immediately, in a way a document circulated for review rarely did.

To build these skills in an agile context, see our Agile Analysis Certification (IIBA-AAC) Training.

A Short Decision Guide

For a team that wants a rule rather than a discussion.

Default to user stories. For most feature work on a product with an available Product Owner, they are faster to write, cheaper to change, and they produce the conversation that improves the item.

Add a use case when the flow has more than about four branches. Beyond that, holding the interaction in stories alone reliably loses paths that nobody remembers to ask about.

Add a use case when the expert is unavailable. If the person who understands the requirement cannot be asked questions during the Sprint, the detail must be written down beforehand.

Add a use case when someone external will build to it. Precision protects both parties in a way a conversation cannot.

Never write both at full detail. Duplicated detail diverges within weeks. If a use case exists, the stories reference it rather than restating it.

Applied consistently that produces a small number of use cases for the genuinely complex parts of a product and stories for everything else, which is what most experienced teams converge on regardless of what they set out to do. Facilitating that judgement in refinement is part of what CSM Certification Training covers.

Closing Thoughts

The comparison is usually framed as old against new, and that framing loses the useful part. Use cases and user stories hold different amounts of detail, and which you need depends on whether the missing detail can be supplied by a conversation.

Where a Product Owner is available and the work is small, stories are clearly better: cheaper to write, cheaper to change, and they produce the discussion that improves the item. Where the flow is complex or the expert is unavailable, the detail has to live somewhere, and a use case is a reasonable place for it.

The thing worth carrying is what stories quietly gave up. Use cases forced teams to enumerate what happens when things fail. Stories do not, and the most common reason work comes back after being called done is an exception path nobody asked about.

That is fixable without returning to use cases. Ask the question in refinement, every time. If you are the person facilitating those sessions, CSM Certification Training covers refinement and the practices that make items genuinely ready. Request the curriculum to see the agenda and upcoming dates, or start with the free CSM practice test to check your grounding.

Sources and Further Reading

• Ivar Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach (1992)
• Alistair Cockburn, Writing Effective Use Cases (2001)
• Mike Cohn, User Stories Applied (2004)
• The Scrum Guide, scrumguides.org