Job Stories: An Alternative to User Stories

Contributor
Apr 15
5 min read

User stories — "As a [role], I want [capability], so that [benefit]" — are the dominant format for capturing requirements in agile teams. They work well when the role drives the requirement. They work less well when the requirement is driven by a situation, not a role.

Job stories reframe requirements around situations and motivations. For some products, they fit better.

The Format

When [situation], I want to [motivation], so that [expected outcome].

Example:

When my checkout fails because of an expired card, 
I want to update the card without re-entering my order, 
so that I don't have to start over.

Three parts:

When: the situation triggering the need
I want to: the motivation or goal
So that: the expected outcome

No "as a [role]" — the situation is the protagonist.

Where Job Stories Fit Better

The user story format assumes the role is the primary driver. "As an admin..." or "As a customer..." Different roles have different needs.

But sometimes the same role has different needs in different situations:

A customer trying to buy
A customer trying to return
A customer trying to find help
A customer trying to compare

The "as a customer" framing flattens these. They're the same person in different situations. Job stories preserve the situation as the primary lens.

Heritage: Jobs to Be Done

Job stories come from the Jobs to Be Done framework (Clayton Christensen, then Alan Klement). The core insight: people "hire" products to do specific jobs. The job is the situation + motivation + outcome.

The same product can be hired for different jobs by the same person. The job changes; the role doesn't. Capturing the job specifically helps design for it.

A Worked Comparison

Same feature, two formats:

User story:

As a customer, I want to save items for later, so that I don't lose them.

Job story:

When I'm shopping but not ready to buy yet, 
I want to save items so I can find them again easily, 
so that I don't lose track of what I was interested in.

The job story captures more context: the situation (shopping, not buying), the motivation (find later), the outcome (don't lose track).

The user story is shorter. The job story is more grounded.

Which is better? Depends on the team. For some teams, the brevity of user stories wins. For others, the situational grounding of job stories wins.

Multiple Jobs, One Feature

A single feature often serves multiple jobs.

For a "save for later" feature:

When I'm shopping but not ready to buy yet → save for later research
When I'm comparing alternatives → save to come back and compare
When I'm price-shopping → save to wait for a sale
When I'm building a list for someone else → save to share

Each job has different specifics. The "save for later" feature serves all of them, but might be designed slightly differently for each. The job story framing surfaces these variations.

When Job Stories Help

Job stories are particularly useful when:

The product is consumer-facing with diverse use cases
The team is in discovery mode, exploring what to build
User research has surfaced specific situations
Multiple "roles" actually have similar needs and the role abstraction obscures more than it reveals

When User Stories Help

User stories work better when:

Role distinctions matter for the product
The team is building features for specific user types (admin, member, guest)
The role drives the requirement (different permissions, different capabilities)
The team is mature with user stories and would slow down switching

You Can Mix Them

Nothing prevents using both formats. Some teams use:

Job stories for early-stage discovery and customer-facing features
User stories for role-based capabilities and internal features

The framework is a tool. Use whichever fits the requirement.

Acceptance Criteria for Job Stories

Same as for user stories. Given-When-Then or plain bullets work for either format.

Job story: When I'm shopping but not ready to buy yet, I want to save items so I can find them again easily.

Acceptance criteria:
- Saved items persist across sessions
- Saved items list accessible from any page
- Items can be moved from saved list to cart with one click
- Saved items show current price (not the price when saved)
- Saved items count visible in header

The format of the story doesn't change how criteria work.

Common Misuses

Forcing every story into job format. Some requirements really are role-driven. Don't force.

Treating job stories as more sophisticated. Different, not better.

Skipping the situation. "I want to save items, so that I don't lose them." The situation is missing. Less useful.

Vague situation. "When I'm using the site." Too broad to be useful.

What Job Stories Reveal

Beyond format, the job-story exercise often reveals:

The same feature serves multiple jobs (worth designing for all)
The product is being hired for unexpected jobs
Some jobs are being met poorly
Jobs you didn't know existed

This is where job stories add value beyond user stories — surfacing the actual situations driving user behavior.

Iteration

Job stories work well in iterative discovery:

Interview users about their actual situations
Draft job stories capturing those situations
Identify which jobs the product currently serves and which it doesn't
Prioritize jobs to address
Build features that serve specific jobs
Validate with users in those situations

This is more discovery-oriented than typical user-story-driven work.

Anti-Patterns

Mechanical conversion. Taking user stories and reformatting as job stories without re-discovering the underlying situations. Just adds words.

Long job stories. "When I'm in this very specific multi-clause situation that's actually three different situations..." Split.

Solution-shaped jobs. "When I want a dropdown menu showing recent items..." That's a solution, not a job.

Job stories as a religion. Insisting on the format regardless of fit. Bad teams find ways to wear the format without changing how they work.

Combining With Other Techniques

Job stories work well with:

Customer journey maps: the journey is a sequence of jobs
User research: interviews surface jobs explicitly
Service blueprints: how the product serves each job

The combination is more powerful than any single technique.

A Working Use

For a team adopting job stories:

Pick a specific feature or product area
Run user research focused on situations (not roles)
Draft 10-15 job stories from the research
Discuss with the team: which jobs are well-served? Poorly?
Pick priorities
Build/refine features against the prioritized jobs

This is more involved than typical story writing. The investment pays back in better-targeted features.

Key Takeaway

Job stories reframe requirements around situations and motivations: "When [situation], I want to [motivation], so that [outcome]." Useful when the situation drives the need more than the role. Particularly valuable for consumer products, diverse use cases, and discovery-mode work. Doesn't replace user stories — both have their place. The combination of formats, used thoughtfully, captures requirements more completely than either alone.

ShiftQuality