User Story vs Use Case: The Difference and Which One to Write

During backlog refinement, the team reads a story: “As a buyer, I want to pay for my order by card so that I receive the goods.” Everyone nods, the estimate is five points, and the story goes into the sprint. Two weeks later, the tester asks what to do if the bank took the money but the store never got a response. There is no answer in the story, or in anyone’s head.

A user story and a use case answer different questions. A story says who needs a capability and why, and stays short: one sentence plus acceptance criteria that make it testable. A use case describes how the system behaves step by step, including all branches where something does not go to plan.

The choice between them depends not on the team’s methodology but on the number of forks in the task: the more forks there are and the more a mistake in a branch costs, the more you need a use case.

There are many comparison tables on this topic. This article takes a different approach: the same payment requirement is written in two ways, so you can see what each version loses.

Two Formats — Two Different Questions

The story format “As a , I want so that ” was coined in 2001 by the team at the London company Connextra. The reason was practical: stories were written by sales and marketing, capturing the desired feature, and developers then had to find the author to understand who it was for and why. The template forced people to write down “who” and “why” right away.

A story is intentionally incomplete. It is a prompt for a conversation, not a specification. Acceptance criteria make it testable: the conditions by which the team and the customer agree that the story is done. Without them, a story remains a wish.

The use case is older. Ivar Jacobson presented it at the OOPSLA conference in 1987, and it spread widely after the 1992 book “Object-Oriented Software Engineering: A Use Case Driven Approach”. A use case describes an actor, their goal, and the steps of their interaction with the system. Alistair Cockburn in “Writing Effective Use Cases” divided it into a main success scenario and extensions — branches where something went differently — and advised enumerating those branches exhaustively.

Both formats can hold requirements of different levels — from a business goal to screen behavior; how to distinguish them is explained in the article how business requirements differ from functional requirements. One more common confusion: a UML use case diagram is not the same as a textual use case. The diagram shows actors and goals, but not steps; where it sits among other notations is explained in the article BPMN and UML: how they differ.

How to word a single functional requirement so that everyone reads it the same way is covered in functional requirements: examples, template and how to write them.

One Task: Paying for an Order by Card

Take an online store: a buyer has placed an order and pays by card through an external payment gateway. The task looks simple, but it has many forks. The card can be declined. The bank can request confirmation, and the buyer can fail it. The gateway may not respond at all. Or it may respond after the store has stopped waiting — and then the buyer has been charged, but the order still shows as unpaid.

Let’s write this task twice.

Version One: A Story with Acceptance Criteria

Story. As a buyer, I want to pay for my order by card so that I receive the goods and do not have to place the order again if payment did not go through the first time.

The second half of the sentence did not come at once. It came from asking “why”: the buyer wants not just to pay, but also to keep the cart they have filled. This changes how the system behaves when a card is declined.

Acceptance criteria:

1. Given: the order is placed, the card is valid. When the buyer confirms payment, then the order gets the status “Paid”, and the buyer sees the order number.
2. Given: the bank declined the card. When the buyer returns to the order, then the cart and delivery details are saved, and payment can be retried with another card.
3. Given: the bank requested confirmation. When the buyer fails it, then the money is not charged, the order remains unpaid and available for another payment attempt.

The story is short and easy to estimate and discuss with the product owner. The value — not losing the order — is visible in the first line.

Version Two: A Use Case with Alternative Flows

Use case: Pay for an order by card. Actor: buyer. Goal: the order is paid.

Main flow:

1. The buyer selects card payment.
2. The system sends the amount and order number to the payment gateway.
3. The buyer enters card details on the gateway page.
4. The gateway confirms payment.
5. The system changes the order status to “Paid” and shows the buyer the order number.

Alternative flows:

• 4a. Card declined. The system shows why the card was declined, the order remains unpaid, and the buyer can choose another card.
• 4b. Confirmation failed. The system does not change the order status and offers to retry payment.
• 4c. The gateway did not respond within the allotted time. The system does not cancel the order but marks it “Awaiting payment confirmation” and requests the payment status from the gateway again.
• 4d. The gateway confirmed payment after the timeout. Based on the gateway notification, the system moves the order to “Paid”. If the order has already been cancelled by then, the system initiates a refund.
• 4e. A payment notification arrived twice. The system processes it once and does not create a second payment.

What Each Version Lost

The story lost branches 4c, 4d, and 4e. These are exactly the ones where money and order status diverge: the buyer has paid, but the store does not know it. They are not visible from the sentence “I want to pay for my order by card”, and they do not come to mind during grooming. They come up in testing or in production — as a message from a buyer who was charged twice or never got the order.

Acceptance criteria can be added, and a good team will add them. But the story format does not force you to look for branches. It forces you to answer “why” and leaves it to the writer to list the failures.

The use case lost “why”. It has steps and failures, but no line that says the cart must be kept. Without asking about value, it is easy to write “the order is cancelled” in branch 4a — formally correct, but the buyer has to fill the cart again and leaves. The use case says how the system behaves, but does not check whether the user needs that behavior.

A story protects against building the wrong thing. A use case protects against building the right thing with a hole in the branch where money goes missing.

What to Write in Your Task

Start by counting the forks. One path, two or three obvious checks — a story with acceptance criteria covers the whole task, and a use case would be bureaucracy. Many branches, each leading to a different state of money, data, or obligations to the client — you need a use case, at least for that part.

Most often, both formats work together. The story brings the task into the backlog and keeps the conversation about value with the business. For the risky part — payment, refunds, integrations with external systems — a use case with alternative flows is attached to it, and the acceptance criteria refer to its branches. This way, estimation and testing rely on one shared list of branches, not on what each person imagined.

If your team uses Scrum, you can still write use cases. If your team writes a formal specification, you can still write stories. Choose the format for the task, not for the process.

How It Sounds in an Interview

In our bank of questions from real interviews, this topic appears 26 times, and 16 of those questions are tagged as junior. That is more than half: the difference between a story and a use case is asked at the entry level.

A weak answer just repeats definitions: “a user story is short and comes from Agile; a use case is long and detailed.” That is correct, but it shows you read the textbook, not that you understand the topic.

A strong answer shows that you see what each format loses. A story holds value but skips branches. A use case lists the branches but does not ask “why”. Then explain how you choose: by the number of forks and the cost of a mistake in them. If you have an example from practice where a branch surfaced late, that is the best argument.