User Stories vs Use Cases vs Job Stories (Examples)

User stories, use cases, job stories and requirement statements are four ways of writing down what software should do. They are often presented as rivals, but they answer different questions at different levels of detail. A user story asks who wants what and why. A use case walks through an interaction step by step, including what goes wrong. A job story starts from the situation the user is in. A requirement states a rule the system must obey.

This guide compares the four, shows the same feature written each way, and explains which to use when. For the basics of writing stories, see our hub guide on how to write user stories.

Quick comparison

User stories

A user story is a short description of a capability, told from the point of view of the person who wants it. The usual format, “As a [type of user], I want [action], so that [benefit]”, came out of the Connextra team in 2001 and spread through Mike Cohn's book User Stories Applied. Stories grew up in Extreme Programming, where they were deliberately brief: Ron Jeffries described each story as a card, a conversation and a confirmation (the 3 Cs). The card is not the specification; the conversation is where details are agreed, and the acceptance criteria confirm them.

Strengths: stories are small enough to estimate and finish in a sprint, easy for non-technical stakeholders to read, and keep the value (“so that”) in view. Mike Cohn sets out the case for them in Advantages of user stories for requirements.

Limits: a backlog of individual stories does not show how they fit together into a flow, and the format makes it easy to skip error cases. Teams fix the first with a user story map and the second with well-written acceptance criteria (see our user story template).

Use cases

A use case describes how an actor (a person or another system) uses the system to reach a goal, as a sequence of steps, together with the ways that sequence can branch or fail. Ivar Jacobson introduced use cases in the late 1980s, and Alistair Cockburn's book Writing Effective Use Cases (2000) set the goal-focused, plain-text style most teams use today (Cockburn's site).

A full use case usually includes:

• Primary actor: who starts the interaction.
• Goal and scope: what the actor wants and which system is being described.
• Preconditions: what must already be true.
• Trigger: what starts the use case.
• Main success scenario: the numbered steps when everything goes right.
• Extensions: alternative and failure paths, each tied to the step where they branch.
• Postconditions or guarantees: what is true at the end, on success and on failure.

Strengths: the extensions section forces you to think about what goes wrong, and the full flow is visible in one place, which is valuable for integrations, payments, and anything audited. Limits: use cases take longer to write and to keep up to date, and one use case is usually too large to build in one sprint.

Use cases have adapted to agile work. In Use-Case 2.0, Jacobson and colleagues split each use case into “slices”, each small enough to plan and test, which play much the same role as user stories.

Job stories (jobs to be done)

A job story replaces the persona with the situation: “When [situation], I want to [motivation], so I can [expected outcome].” The idea was first mentioned by Paul Adams on the Intercom blog and developed by Alan Klement, who explained it in a 2013 Intercom guest post, Using job stories to design features. It applies jobs-to-be-done thinking, associated with Clayton Christensen, to feature design.

The argument for job stories is that “As a busy parent” carries assumptions the team cannot test, while the situation (“When I'm about to leave the house and realise I forgot to order groceries”) explains the urgency, the constraints and what “done” feels like to the user. Two very different personas in the same situation often need the same thing.

Strengths: job stories are good in discovery and design, keep the team focused on context, and produce better questions for customer interviews. Limits: they say little about who is allowed to do what, which matters for permissions and roles, and most teams still turn them into user stories or tasks for planning.

Requirement statements

The traditional format is a numbered statement: “The system shall lock an account after five failed sign-in attempts.” Requirement specifications are still the norm in regulated industries, government tenders and fixed-price contracts, and the current international standard for writing them is ISO/IEC/IEEE 29148.

Agile teams use requirement statements too, mostly for non-functional requirements (performance, security, availability, accessibility) that apply across many stories. Those are often recorded once, in the definition of done or a short quality-attributes page, rather than repeated on every story.

The same feature written all three ways

Feature: in a shared-expenses app for flatmates, a person pays for something and splits the cost with others.

As a user story

As a flatmate who paid for a shared purchase, I want to split the cost with the people it was for, so that everyone's balance shows what they owe me.

• I can choose which group members share the cost; I am included by default.
• The default split is equal; I can switch to exact amounts or percentages.
• The app will not save a split whose parts do not add up to the total, and says by how much it is off.
• Each person's balance updates as soon as the expense is saved, and they get a notification.

As a use case

Use case: Split an expense. Primary actor: Payer. Precondition: the payer is signed in and belongs to a group with at least one other member. Trigger: the payer chooses “Add expense”.

1. The payer enters the amount, a description and the date.
2. The system shows the group members, with the payer selected.
3. The payer selects the members who share the cost.
4. The system proposes an equal split and shows each share.
5. The payer confirms.
6. The system saves the expense, updates every balance and notifies the selected members.

• 4a. The payer switches to exact amounts or percentages: the system recalculates as each value is typed.
• 5a. The shares do not add up to the total: the system blocks saving and shows the difference.
• 6a. The device is offline: the system saves the expense locally, marks it as pending and syncs when back online.
• Postcondition on success: the expense is recorded once, and every balance reflects it. On failure: no balance changes.

As a job story

When I've just paid for something at the till that's partly for my flatmates, I want to log it before I forget the amount, so I can get paid back without chasing anyone.

As requirement statements

• REQ-1: The system shall allow a group member to record an expense with amount, description, date and payer.
• REQ-2: The system shall allow the payer to divide an expense equally, by exact amounts or by percentage.
• REQ-3: The system shall reject a division whose parts do not equal the total.
• REQ-4: The system shall update all affected balances within two seconds of saving.

Look at what each version surfaced. The user story is the easiest to estimate and plan. The use case is the only one that raised the offline case and stated what must be true if saving fails. The job story revealed the real constraint, which is speed at the till; it suggests the first screen should ask for the amount and nothing else, something none of the other versions would have prompted. The requirements added a measurable performance target that the story left implicit.

Which one should you use?

Can you combine them?

Yes, and most mature teams do. A workable sequence looks like this:

1. Use job stories while you research, to capture situations and motivations from real users.
2. Arrange the resulting capabilities on a story map as user stories, and pick the first release slice.
3. For the one or two flows where failure is expensive (payments, sign-up, data sync), write a lightweight use case to find the extensions, then turn each extension into its own story or acceptance criterion.
4. Record cross-cutting requirements (performance, security, accessibility, compliance) once, as numbered statements or in the definition of done.

The rule of thumb: write only as much as the team needs to build the right thing safely. A three-person MVP team does not need a requirements document, and a bank integration should not rest on a single sentence.

Common mistakes

• Writing use cases as user-interface scripts (“the user clicks the blue button”), which ties the requirement to a design that will change.
• Writing user stories with no “so that”, which leaves the team unable to suggest a simpler solution.
• Treating a job story as a persona in disguise (“When I am a busy mum...”); the situation should be a moment, not an identity.
• Copying a long requirements list into a backlog as one story per line, which produces stories with no user and no value.
• Using different formats in the same backlog with no agreement on which is the source of truth.

Frequently asked questions

Not sure how much specification your product needs? We help founders turn ideas into a scoped backlog and then build it in short sprints. See our monthly development plans.