Job Stories: An Alternative to User Stories

The feature the persona hid

A team I'll describe from a familiar composite spent a sprint building "save for later." The backlog item was clean, INVEST-shaped, and approved without argument: As a user, I want to save items for later, so that I can buy them another time. They built a wishlist — a heart icon on every product, a saved-items page reachable from the account menu. It shipped. It got used about as much as the empty-state placeholder they'd worried over. Then support started forwarding a pattern of complaints that didn't fit: people abandoning carts, then writing in confused about where their cart went. The team had built a wishlist. What customers were reaching for was a way to pause a checkout they weren't ready to finish — a different feature, at a different moment, in a different part of the app.

Nothing in that story is a coding failure. The wishlist worked exactly as specified. The failure happened earlier, in the sentence everyone signed off on. "As a user, I want to save items for later" names a role and a verb and stops. It never asks the question that decides the design: save them from where, and why right now? The persona form let the team skip straight past the one thing they most needed to discover — and a job story is, at bottom, a template that won't let you skip it.

If your current backlog item could be satisfied by two features that live in completely different screens, the sentence isn't finished. It's naming a want, not a situation.

Why "As a role" reads as rigor and isn't

The user-story template — As a [role], I want [capability], so that [benefit] — earned its place. It forced teams off "the system shall" spec-speak and onto human intent, and it pairs cleanly with INVEST criteria for keeping items small and testable. Its problem isn't the "so that." Its problem is the "as a."

The role slot invites a persona, and a persona is a proxy. "As a user," "as a customer," "as an admin" — these feel like context because they name a human, but most of the time they carry almost no information about the decision in front of you. The tell is mechanical: read your story and swap the role for a different one. As a customer, I want to save items for later. As a shopper, I want to save items for later. As a visitor… If the feature doesn't change when the role changes, the role is decorative. It's occupying the one slot in the sentence that's supposed to hold context, and holding none.

Meanwhile the thing that would have changed the design — the customer was mid-checkout, card in hand, but blocked on a decision — has no slot at all. The template doesn't ask when, so nobody wrote it down, so nobody built for it.

Run the swap test on your top five backlog items right now. Every story whose role can be replaced with a synonym without changing a single acceptance criterion is a story whose role is carrying no weight — and probably hiding a situation you haven't elicited yet.

The mechanism: situation-first forces the elicitation persona-first skips

Here's the actual gear that turns, because this is the part that matters. Discovery has one job: find out what "right" means before you build it. For a feature, "right" is almost always decided by the trigger — the specific circumstance that makes someone need this thing at this moment — and the motivation underneath it. That trigger is the expensive thing to learn. It only comes out of watching real behavior or asking real elicitation questions: what were you doing right before you wanted this? what were you worried about? what would you have done if it weren't here?

The persona-first template lets you answer none of that and still produce a grammatical, approvable story. "As a user" is a slot you can fill from your chair. So the template quietly converts a discovery question into a fill-in-the-blank, and the team pays for the skipped discovery later — in a shipped feature aimed at the wrong moment.

The job-story form — When [situation], I want to [motivation], so I can [expected outcome] — closes that escape hatch by making the situation the first thing you have to write. You cannot complete the sentence honestly without naming a trigger, and you cannot name a trigger you haven't discovered. The format doesn't make the team smarter. It makes the un-discovered gap visible as a blank instead of hiding it behind a plausible persona. That's the whole mechanism: situation-first framing surfaces the context that persona-first framing drops, because it puts the hardest-to-fake slot first.

Take one story you're unsure about and try to rewrite its "As a role" opener as a "When [situation]" opener. If you can't fill the when without inventing it, you've found a requirement you're currently guessing at — that blank is the discovery you owe.

The artifact: one feature, two forms, two different builds

(Developed example — a simple scenario.)

Return to "save for later" and put the two story forms side by side, then follow each one down to the acceptance criteria it actually produces. The point isn't that the words differ. It's that each sentence forces a different build, and you can see exactly where they fork.

The user story the team shipped:

As a user, I want to save items for later, so that I can buy them another time.

Acceptance criteria that fall out of it:

• Given a product page, when I click "save," the item is added to my saved list.

• Given my account menu, when I open "Saved items," I see everything I saved.

• Given my saved list, when I click an item, I go to its product page.

That is a wishlist. Every criterion is about a persistent list attached to an account. Nothing in the sentence points anywhere near a cart or a checkout, so nothing in the criteria does either.

The job story that surfaces after real situation-focused discovery:

When I'm mid-checkout with items in my cart but I'm not ready to commit — I need to check with my partner, or wait for payday — I want to set the whole cart aside without losing it, so I can pick up exactly where I left off when I come back.

Acceptance criteria that fall out of that:

• Given a full cart at checkout, when I choose "save this cart," the cart state — items, quantities, selected options — is preserved intact.

• Given a saved cart, when I return (even on another device), I can restore it to checkout in one step with nothing re-entered.

• Given a saved cart, when I restore it, I land back at the checkout step I left, not at square one.

• Given a saved cart, when an item's price or stock changed while it was parked, I'm told before I pay.

Same four words in the title — "save for later" — and a completely different feature: it lives at checkout, not the account menu; it preserves cart state, not a list of product IDs; it has a re-entry flow and a stale-data edge case the wishlist never has to think about. The user story didn't just under-specify this. It pointed the team confidently the wrong way, because its only real content — the role — was inert, and its situation — mid-checkout, not ready — was structurally absent. The job story is longer and less tidy, and that's the feature working: the mess is the context the template refused to let anyone drop.

Notice what the job story is not doing, too — it isn't prescribing a solution. "I want to set the whole cart aside" is a need, not a UI. That distinction is the difference between a job story and a use case, which is the right tool once the interaction itself is what you're specifying.

Job story vs user story, honestly compared

Neither form is a general upgrade. They surface different things and hide different things, and the choice is about which risk you're currently exposed to.

	Job story	User story
What it forces you to name	The trigger — the specific situation and moment the need fires	The role or persona the capability serves
What it hides	Genuine role differences (a job story flattens who is acting)	The trigger — when and why, the thing discovery exists to find
Fails quietly when	You invent a plausible situation instead of eliciting a real one	The role is a synonym-swappable placeholder carrying no context
Best fit	Consumer/discovery work; features where the same person acts differently in different moments; anything you suspect you don't understand yet	Distinct roles with genuinely different permissions or capabilities; internal/admin tools; a domain the team already understands well

The rows that matter most are the two "hides." A user story can hide the trigger behind a confident persona. A job story can hide a real role distinction — if a lender and a borrower truly need different things, "When I'm reviewing a loan…" erases exactly the difference that should drive the design. You pick the form that hides the thing you can least afford to lose sight of.

When the user story is the right call

Situation-first is a default for discovery, not a rule for everything — and forcing every backlog item into job-story shape is its own anti-pattern. The persona form is genuinely the better choice when the role is the requirement, not a proxy for one.

Concretely: you're building role-based access where an admin, an auditor, and a standard user must see different things and the differences are the feature. Here the role slot is load-bearing — swap "admin" for "auditor" and the acceptance criteria change, which is exactly the swap test passing. Or the team is fluent in user stories, the domain is well-understood, and the work is incremental extension of a known capability rather than exploration — reframing mature, well-specified backlog items into job stories buys nothing but churn. If your capability is defined by who is allowed to do it, keep the role in the sentence; the plain-language user-story-plus-INVEST discipline is the right tool and job stories would only blur it.

Before you reframe a story, check the swap test one more time: if changing the role genuinely changes the criteria, the user story is already doing its job — leave it.

What to do differently on your next backlog

Don't convert your backlog. Run one diagnostic pass on it. Take your current stories and, for each one, do two things: run the swap test (replace the role with a synonym — does anything change?), and try to write its "When [situation]" opener from what you actually know. Sort the results into three piles.

• Role changes the criteria → leave it as a user story. The persona is real; the form fits.

• Role is inert, but you can name the real situation → rewrite it as a job story now. You already did the discovery; you were just hiding it in the wrong slot.

• Role is inert, and you can't name the situation without inventing it → stop. This is the valuable pile. Each of these is a feature you're about to build on a guess. Take it back to elicitation — watch the moment, ask the trigger questions — before it earns a place in the sprint.

That third pile is the entire payoff. Job stories don't write better sentences; they change what you do when you can't finish one — they turn a silent assumption into a blank you're forced to go fill. The next time a story slides through review because "As a user, I want…" sounds finished, put your finger on the role and ask whether any other role would change the build. If the answer is no, you're not looking at a requirement yet. You're looking at the place your discovery stopped early — and now you know how to see it.