Job Stories
A job story is a statement of need in three segments: the situation that triggers the need, what the stakeholder wants at that moment and the outcome they expect from it. Its common form is "when situation, I want to motivation, so I can expected outcome". The first segment carries a moment and its context where the user story carries a role, which moves design toward the circumstances that push someone to act. The format comes out of product practice. Working from Jobs to Be Done theory, the Intercom team put it together in 2013 and Alan Klement gave it its name. The Agile Extension to the BABOK Guide lists it among the lightweight formats for carrying a backlog item.
Goal
A job story describes a product backlog item as a job a stakeholder has to get done at a given moment. The sentence names the situation that triggers the need, what the person is after at that instant and the outcome they expect from it. The phrase job to be done, the task someone is trying to see through, comes from the theory of demand set out by Clayton Christensen: a product is "hired" to get a job done, and that job explains the purchase better than the buyer's profile.
The format addresses a design defect: a requirement assigned to a role says who acts without saying why. Two people with nothing demographic in common meet the same trigger and want the same thing; one person meets that trigger in different roles depending on the day. Klement made the argument in 2013 against the persona, the archetypal user portrait built on demographic and behavioural traits: an imaginary customer whose traits explain no causation. The situation carries the context of the moment, material the delivery team uses to design.
The deliverable is the sentence itself, put on the backlog and refined like any other item.
Usage
When to use it
- A need triggered by a specific moment: what prompts the action weighs more than who acts.
- A situation shared by several roles: one trigger carries distinct motivations.
- User experience design: the situation supplies the constraints of the moment.
- A backlog drifting toward the solution: the format forces the need to be stated before any feature.
- Cause-and-effect reasoning: tie a trigger to an expected outcome, then check whether the outcome happened.
- Refinement inside the delivery team: the format is practised on items already on the backlog.
When not to use it
- Permissions to specify: the sentence leaves out the role and with it the access rights; take a roles and permissions matrix.
- Behaviour rich in alternative paths: three segments carry neither flows nor exceptions; take use cases.
Description
The shape of the sentence
A job story is written in the first or the third person. The first lets the stakeholder speak: "when situation, I want to motivation, so I can expected outcome". It reads left to right as a causal chain: a trigger, a need it raises and a state the person wants to reach.
The three elements
The situation gives the context of the moment when the job has to be done. It names a trigger and what surrounds it: what has just happened, what is pressing, what is unknown, where the person is. The richer the context, the better the team designs.
The motivation names what the stakeholder is trying to obtain. It admits internal forces, worry, haste, habit, as well as external ones, a deadline, an invoice, a third party waiting. The format keeps the feature out of it: writing "I want a button on the home screen" closes the design, and the team inherits a solution.
The expected outcome says what satisfies the motivation or what eases it. It is phrased as a state the person reaches, which makes it observable once the solution is delivered.
One situation, several actors
A single trigger sometimes mobilises several people with different needs. Their roles then enter the "when" segment and the sentence moves to the third person: "when someone situation, actor wants to motivation, so that expected outcomes". The situation stays single and the motivations multiply, one per actor, before converging on a common outcome. In user stories, one role per card means writing as many cards as there are roles and leaves the link between them implicit.
Writing a job story
- Collect the situation in the field
The trigger is an empirical fact. It comes from an interview, from an observation at the workplace, from a support ticket or from a usage recording. A situation written from the office is a hypothesis dressed up as a fact. - Write the context in the words of the person observed
Project vocabulary smooths away what makes the constraint: "the system is slow" has replaced "I have three patients waiting at the desk". - Work back from the feature to the need
When the person interviewed asks for a screen, a button or a report, ask what it would be for and write down the answer. The motivation is what is left when no interface object is named any more. - Name the expected outcome and the data that shows it
An outcome nothing allows anyone to observe will never be checked: name at the same time where the effect will read, a count, a usage log or a call volume. - Have the sentence reviewed by someone from each role concerned
A shared trigger is confirmed there: each role recognises the moment and corrects its own motivation. The sentence then moves to the third person. - Put the sentence on the backlog and split it
A job story splits into smaller job stories, each of which goes back through refinement and prioritisation. - Attach acceptance criteria before estimating
The format supplies none, so the team picks the form: executable examples, a list of conditions or classic acceptance criteria. That choice is settled once for the whole backlog.
Job story or user story
The two formats occupy the same place on a backlog and differ by a single segment, the first. The segments that follow keep the same function.
| User story | Job story | |
|---|---|---|
| First segment | A role or a persona | A situation, the moment and its context |
| What the format keeps out of the sentence | The detail, deferred to the conversation | The feature, deferred to design |
| Quality heuristic | INVEST, Bill Wake's six quality criteria | None supplied with the format |
| Verification | Acceptance criteria, a defined element of the technique | For the team to attach |
| Several roles for one job | One card per role | One statement, the actors enter the "when" |
| Origin | Extreme Programming, late 1990s | Jobs to Be Done, applied to software in 2013 |
The situation is the right first segment when the moment of the trigger governs what gets built: interaction design, a path through the service that several profiles share, the question of "why now". The role takes over again as soon as a boundary on access rights has to be documented or a verification has to be held to discipline. The user story then arrives with INVEST.
The Agile Extension expects the two to coexist: the job story carries the motivation and the expected outcome, the user story carries the candidate feature. The guide states the risk that goes with it, a team that loses its way switching between formats. In practice, one format is reserved for one phase, discovery for instance, rather than mixing the two in a single queue.
What makes a job story fail
The persona put back into the situation
"When I am a system administrator" puts a role in the situation segment. Writing who the person is there brings back the persona bias the format sets aside.
The solution slipped into the motivation
"I want a CSV export" looks like a motivation and the sentence stays well formed; it is an order for a feature that leaves nothing to design.
The sentence that swells
The format is wordier than the user story, since it carries the context, the actors and the outcomes. Past three lines, the job story stops being readable in a refinement meeting. Keep the context to what changes a design decision.
The expected outcome that restates the motivation
"I want to know my balance so I can know my balance" is a wasted segment. The expected outcome sits beyond the application, in what the person decides or avoids thanks to it.
Decomposition left unattended
A job story of the right size splits into five or six smaller sentences. Each arrives on the backlog with a priority to set and refinement to run; without that management, splitting lengthens the queue and clarifies nothing.
Acceptance criteria never written
The format asks for none. A team that adopts it without giving them a thought ends up with sentences rich in intent that nobody can say are satisfied.
AI considerations
A model renders three services on this format. It converts a corpus: a batch of user stories, support tickets or interview verbatims becomes a list of candidates for the three segments, which the team then corrects. It checks mechanically what the format leaves unchecked: the feature slipped into the motivation segment, the role disguised as a situation, the expected outcome that restates the motivation. Those are defects of form. It varies the situations: from an observed trigger it proposes variants of the same moment under other constraints, at night, offline, on the move, for the team to keep or discard.
The limits come from the material of the first segment. The situation is field data: a model produces plausible triggers nobody has lived through, and a job story built on an invented moment recreates the persona bias. The worries and frictions the motivation has to carry come from real customers, heard or observed; generated, they describe only the regularities of the training corpus. Prioritisation stays a business decision, driven by the value and the frequency particular to that organisation. Finally, support tickets and interview verbatims carry personal data within the meaning of the FADP, the Swiss data protection act, often health or financial data, and do not go into a public service without a legal basis or anonymisation.
Examples
A health insurer is considering adding to its app a running total of the annual deductible, the franchise. Interviews in its branches surface one recurring moment: the doctor proposes a treatment that can wait, and the insured person does not know where their annual deductible stands. The need is then written in one sentence.
"When my doctor proposes a non-urgent treatment in November and I do not know where my annual deductible stands, I want to see the share already used and what I would pay myself if I start now, so I can decide whether to book the appointment this year or in January."
The situation runs to "annual deductible" and carries everything that makes the decision possible. The motivation lies in the two amounts the insured person is after, without naming the screen that will show them. The expected outcome is the date they will set.
A thirty-year-old policyholder and a retiree live this situation identically, so the screen to design is the same for both. A user story would have had to pick a role, a distinction with no effect on the design.
Under LAMal, the compulsory health insurance act, the deductible resets on 1 January: someone who has already reached it pays only the co-payment until 31 December, and postponing the care starts them again on a full deductible. A readable running balance therefore concentrates the non-urgent care of these policyholders in the last weeks of the year, an effect the insurer reads in its statements. The motivation itself stops at the need and leaves several solutions open: a notification in November, a cost-sharing simulator, a reminder in the quarterly statement.
Visualisations
The multi-actor case is a branch, one situation toward several motivations then a common outcome, a shape no list conveys. The comparison with the user story is a swap of position, drawn by aligning the two sentences segment by segment. The technique finally produces a segmented sentence, labelled blocks: the job story card shows the three segments and what each of them carries. The substantive differences between the two formats are made of rows and columns and belong in a table.
Cost
| Phase | Level | Rationale |
|---|---|---|
| Preparation | Medium | The situation comes from the field, so from interviews, observations or a sift through support tickets. Without that material the team writes moments that are plausible and false. |
| Execution | Low | Once the trigger is known, the sentence takes a few minutes to write and is reviewed in a refinement session with no tooling or particular training. |
| Documentation | Medium | The format is wordier than the user story and brings neither acceptance criteria nor a quality test: the team adds that layer and keeps it current at every split. |
Tooling
The job story is a writing convention, so the tool is whatever medium the sentence lives on. The whiteboard and sticky notes are enough in a workshop, with a three-band template drawn once and for all: the visual constraint of the three segments makes the rushed segment show. Collaborative boards (Miro, Mural, FigJam) hold the same role for a distributed team and keep the variants of one situation side by side.
Backlog management tools (Jira, Azure DevOps, GitLab) take the sentence in as soon as it has to be prioritised, estimated and linked to whatever satisfies it. Two settings are enough there: a ticket template that imposes the three segments as separate fields rather than one free-text block, as well as a label that tells job stories from user stories when both formats coexist. The segments then become filterable, which is how every backlog item attached to one situation is found again.
User research tools and support platforms (Dovetail, Zendesk) are upstream the source of the situations, since they hold the verbatims where the triggers appear. No tool is required: three segments written in marker pen on a strip of paper are a complete instance of the technique.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.4 Job Stories: the definition, the first and third person, the three elements (situation, motivation, expected outcome), the strengths of the format and its limits, among them verbosity, decomposition to be managed and the confusion between formats on one backlog.
- Alan Klement, Replacing The User Story With The Job Story, 2013: the origin of the term and of the three-segment sentence, with the argument against the persona.
- Paul Adams, Designing Features Using Job Stories, Intercom: the version applied to feature design, in the "when, I want to, so I can" form the Agile Extension takes up.
- Clayton M. Christensen, Taddy Hall, Karen Dillon, David S. Duncan, Know Your Customers' Jobs to Be Done, Harvard Business Review, 2016: the Jobs to Be Done theory the format inherits from.