Job stories are short backlog statements in the form "When [situation], I want [motivation], so I can [outcome]". They describe the context and the need, not the user role or the solution. You write them from customer interview data: the richer the situation in the "When" part, the better the story. Once you have them, five mechanics turn jobs into product value: kill jobs, uncover sleeping jobs, remove "tax" jobs, open new segments, and add new jobs.
Last verified: October 2026.
This post is about the writing process and the value mechanics. For the basic comparison of the two formats and how to split large items, see User Stories, Job Stories, and Decomposition.
What a job story is, and where it came from
A job story is a one-sentence description of a job a person needs to get done, anchored in the situation that triggers it.
The format came out of Intercom's product team. Paul Adams, then at Intercom, wrote that the team looked for something better than personas, built the format on Jobs to Be Done (JTBD) ideas, and that "Alan Klement later named it for us" (Intercom, 2016). Klement's article "Replacing the User Story with the Job Story" circulated in September 2013 (Populi, 2013), and he expanded it in a December 2013 guest post on the Intercom blog.
User stories are older. Wikipedia credits Kent Beck with introducing them on the Chrysler C3 project in 1997, and Mike Cohn's User Stories Applied (2004) became the standard reference (Wikipedia: User story). The jobs idea itself has another line: Anthony Ulwick's Outcome-Driven Innovation (ODI), whose first patent was granted in 1999 (Wikipedia: Outcome-Driven Innovation).
| Format | Template | Focus | Typical source |
|---|---|---|---|
| User story | As a [role], I want [feature], so that [benefit] | Who and what | Stakeholder requests |
| Job story | When [situation], I want [motivation], so I can [outcome] | Context and why | Customer interviews |
| Gherkin scenario | Given / When / Then | Behavior of a solution | Refinement, testing |
Why job stories matter for the PSPO I exam
Job stories matter for the Professional Scrum Product Owner I (PSPO I) exam because the exam tests value and backlog management, not a story template.
Scrum.org lists Product Value, Product Backlog Management, and Stakeholders & Customers among the PSPO I focus areas (Scrum.org). The Scrum Guide 2020 never mentions user stories. It says the Product Owner is accountable for "creating and clearly communicating Product Backlog items" and that refinement adds details "such as a description, order, and size" (Scrum Guide 2020). So any format is allowed, and the exam rewards answers that tie backlog items to customer value. You can practice that reasoning on the PSPO I exam simulator.
What a "job" means before you write anything
A job is a task a person needs to get done; small jobs serve bigger ones.
I learned the term from Ivan Zamesin, author of the Advanced Jobs To Be Done (AJTBD) methodology and the course "How to Make a Product" (zamesin.ru). His definition goes deep: a job is an aim the brain sets to satisfy a psychological need. I had to read it twice before it clicked. In practice I use "task" and "sub-task" as working synonyms. Deep needs sit under many layers of a person's life and take a skilled researcher to reach. Jobs sit closer to the surface and you can observe them.
Van Neistat makes the same point in his video "Your tardy friends suck. 7 Principles": getting somewhere on time is made of many small jobs, like finding keys, tying shoes, and opening a map app. Each small job is a place where a product can help or get in the way.
How to write job stories from interview data
You write job stories by turning each interview episode into three parts: the situation, the wanted result, and the reason it matters.
Step 1. Collect episodes, not opinions
Ask people about the last time they did the job: where they were, what they had, what went wrong. Concrete past episodes give you the "When". Opinions about the future give you nothing to write. The elicitation techniques used in business analysis apply here.
Step 2. Write the "When": stack the context
The "When" describes the situation the person is in before any product exists. It can include emotions, money, family, time pressure, and where they are. You can combine contexts with "AND". The only rule: the more context, the better. Klement gives the same advice: add when and where the task happens, and the anxieties involved (Intercom).
Step 3. Write the "Want": the result, not the feature
The "Want" is the concrete result the person needs in that situation. It describes the problem to solve. It can mention a solution, but it should not be built around one. "I want a dropdown" is a feature. "I want to know my order went through" is a result.
Step 4. Write the "So": find the bigger job
The "So" explains why the want matters. It often points to a higher-level job, such as feeling confident or feeling good. In real interviews it is usually specific rather than abstract, and that is fine.
Step 5. Put it in the backlog and keep the conversation
A job story is a Product Backlog item like any other. During refinement the team adds detail, size, and acceptance criteria, and may write Gherkin scenarios for the chosen solution.
Job story examples
Each example below shows how much the "When" part can carry.
- Simple, close to a user story: When an order is submitted, I want to see a confirmation message, so I can avoid submitting it twice.
- Stacked context: When I am looking for a new place to live AND I have a dog AND I live with my partner, I want to find a place that fits all our needs, so we can keep a good quality of life.
- Money and emotion: When I don't have much money AND I see a new pair of shoes AND I have an important in-person meeting soon, I want to buy that pair, so I feel confident at the meeting.
- Catering: When I want to eat healthy AND I have no time to cook or choose recipes, I want a balanced meal delivered to my door, so I can stick to my diet without spending evenings in the kitchen.
The shoes example shows why job stories help. A user story ("As a customer, I want to buy shoes") hides the real job: feeling confident at the meeting. That job has competitors outside the shoe store.
Five ways to create value from jobs
Once jobs are written down, value comes from changing the set of jobs a person has to do. These five mechanics come from Zamesin's course (zamesin.ru).
| Mechanic | What changes | Example |
|---|---|---|
| 1. Kill unnecessary jobs | Remove steps needed to get the main job done | Catering removes shopping, choosing recipes, cooking |
| 2. Uncover sleeping jobs | Reveal a job people did not know they had | Products nobody asked for until they existed |
| 3. Remove "tax" jobs | Eliminate friction people tolerate | Wireless earbuds remove untangling cables |
| 4. Open new segments | Serve the same job for new groups | A product line extended to new price and use tiers |
| 5. Add new jobs | Let the product do more jobs | An existing product takes on an adjacent job |
1. Kill unnecessary jobs
Every main job has helper jobs. Remove one and the product gets better. I send parcels in Poland with InPost, and the app lets me drop a parcel at a parcel machine without printing a label: it gives a code to enter at the locker (InPost). The "find a printer" job is gone. Catering does the same for the healthy-eating job in the example above.
2. Uncover sleeping jobs
A sleeping job is one customers do not know they have yet. Peter Drucker, in The Essential Drucker, notes that no one knew they wanted a copier or a computer until these became available. Finding sleeping jobs is hard and valuable. Interviews rarely surface them directly; you see them in workarounds.
3. Remove "tax" jobs
A tax job is friction people accept as the price of the main job. Wired earphones came with a tax: untangling the cable before a call. Wireless earbuds removed it, and a better microphone removed another one: holding the cable near your mouth.
4. Open new segments for the same jobs
The same job exists in different contexts and budgets. Apple added over-ear AirPods Max in 2020 next to its in-ear line. My half-serious theory is that many people in IT buy them to look better on video calls. That is a different "So" for the same "listen to audio" job.
5. Add new jobs to your product
A product can take on jobs that sit next to the one it already does. The risk is diluting the main job, so check each new job against interview data before adding it.
What practitioners report
Teams that switched report more discussion of outcomes and fewer untested assumptions about users.
- Kyle Fiedler of thoughtbot wrote in 2015 that his team expected little from the wording change, but the result "has far surpassed" expectations (thoughtbot). Dropping "As a [persona]" removed unvalidated assumptions, and starting with the situation led to talks about desired outcomes.
- Mike Cohn (Mountain Goat Software) writes both formats in the same week. He suggests job stories when users have similar needs and the "when" matters more than the "who" (Mountain Goat Software).
- Professional Scrum Trainer Chris Belknap advises: "Use job stories when the situation matters more than the role" (Scrum.org, 2025).
- In a 2017 Agile Uprising forum thread, a coach who taught a whole company job stories reported "Developers and testers commented it was easier to write ACs" (Agile Uprising). Other participants warned against swapping one template habit for another.
Common misconceptions
Most mistakes come from treating job stories as a new template instead of a research output.
- "Job stories replace interviews." They are the output of interviews. Without real episodes, the "When" is invented.
- "A job story is a user story with the role deleted." Deleting the role without adding context gives a weaker story. Cohn notes you can add the role back when it matters.
- "The Want should name the feature." The Want names the result. The solution comes in refinement.
- "Scrum requires one story format." The Scrum Guide prescribes no format for Product Backlog items.
- "The So is always abstract." Higher-level jobs like "feel good" show up, but most real "So" parts are concrete.
Practice Questions
Question 1
A Product Owner replaces As a user, I want a delivery tracker with When I'm waiting for a parcel AND I work from an office, I want to know when it arrives, so I can be there to collect it. What is the main benefit?
A. The item no longer needs refinement B. The item exposes the context and outcome, so the team can consider different solutions C. The Scrum Guide requires the When / Want / So format D. The item becomes estimable without the Developers
Answer: B. The context and outcome open the solution space (notifications, locker delivery, a delivery slot). Refinement is still needed (A), Scrum prescribes no format (C), and sizing is done by the Developers (D) (Scrum Guide 2020).
Question 2
Interviews show customers spend ten minutes finding a printer to print a return label. Which value mechanic does a "return by code" feature use?
A. Open a new segment B. Add a new job C. Kill an unnecessary job D. Uncover a sleeping job
Answer: C. Printing is a helper job on the way to the main job (returning the item). Removing it kills an unnecessary job.
Question 3
Who is accountable for making sure job stories in the Product Backlog are clearly communicated and ordered?
A. The Scrum Master B. The Developers C. The stakeholders who were interviewed D. The Product Owner
Answer: D. The Scrum Guide makes the Product Owner accountable for creating and clearly communicating Product Backlog items and ordering them. The Product Owner may delegate the work but stays accountable.
Related techniques
Job stories work best alongside other backlog and analysis techniques:
- User Stories, Job Stories, and Decomposition: format comparison, INVEST, vertical slicing.
- Backlog refinement: where job stories get detail, size, and order.
- Acceptance and evaluation criteria: how to define "good enough" for the chosen solution.
- Behavior-Driven Development (BDD): Given / When / Then scenarios for the solution behavior.
- Elicitation and collaboration: interview techniques that produce good "When" data.
FAQ
What is the format of a job story?
A job story follows "When [situation], I want [motivation], so I can [expected outcome]". The situation describes the context before any product exists. The motivation is the result the person needs. The outcome explains why it matters and often points to a higher-level job.
Who invented job stories?
The format came from Intercom's product team, which built it on Jobs to Be Done ideas. Alan Klement named it and described it in 2013 articles, including "Replacing the User Story with the Job Story". Paul Adams later told the story on the Intercom blog.
When should I use job stories instead of user stories?
Use job stories when the situation matters more than the role, for example when most users have similar needs. Use user stories when different roles need different things. Many teams use both in the same backlog.
Are job stories on the PSPO I exam?
The PSPO I exam does not test any story template, and the Scrum Guide does not mention user stories or job stories. It tests whether you manage the Product Backlog to maximize value. Knowing job stories helps you reason about value and customer needs in scenario questions.
How many context details should the "When" part have?
As many as the interview gave you. Stack them with "AND": money, emotions, family, location, time pressure. A richer situation makes it easier to spot the real job and its competitors.
Sources
- How we accidentally invented Job Stories — Paul Adams, Intercom (2016)
- Designing features using Job Stories — Alan Klement, Intercom (2013)
- Alan Klement: Replacing the user story with the job story — Populi (2013)
- User story — Wikipedia
- Outcome-Driven Innovation — Wikipedia
- Ivan Zamesin — AJTBD and the "How to Make a Product" course
- Van Neistat — Your tardy friends suck. 7 Principles (YouTube)
- The Scrum Guide 2020
- Professional Scrum Product Owner I — Scrum.org
- Converting to Jobs Stories — Kyle Fiedler, thoughtbot (2015)
- Job Stories Offer a Viable Alternative to User Stories — Mike Cohn, Mountain Goat Software
- User Stories Sometimes Do More Harm Than Good — Chris Belknap, Scrum.org (2025)
- Is the User Story Dead? — Agile Uprising Coalition (2017)
- Send a parcel without printing a label — InPost
- Apple introduces AirPods Max — Apple Newsroom (2020)
- Peter F. Drucker, The Essential Drucker (HarperCollins)