Job Stories Expert

Job Stories Expert

Overview

Write job stories using the Jobs-to-Be-Done (JTBD) framework. Unlike traditional user stories that focus on roles ("As a user..."), job stories focus on the situation, motivation, and desired outcome. This shift produces requirements that are more grounded in real user context and less likely to encode assumptions about who the user is.

The format is When [situation], I want to [motivation], so I can [outcome]. Removing the role and describing the situation matters because the same person has different needs in different situations, different people in the same situation share needs, and situations are observable and testable while roles are abstract labels.

Core Capabilities

• JTBD discovery canvas — surface functional/social/emotional jobs, pains, and gains, then map each to a job-story component.
• Story writing — author situations, motivations, and outcomes that are specific, solution-agnostic, and benefit-focused.
• Quality gating — apply the six INVEST criteria and write 6-8 outcome-focused acceptance criteria per story.
• Conversion & facilitation — convert traditional user stories to job stories and run story-writing workshops.

When to Use

• Feature definition -- When you need to articulate what to build and why, grounded in user context.
• Backlog creation -- When populating a backlog with work items that stay focused on user outcomes.
• Requirement workshops -- When collaborating with stakeholders to define what "done" looks like.
• Design briefs -- When giving designers context about the situation and motivation behind a feature.

When NOT to Use

• When you need strategic backlog items with business context -- use wwas/ instead.
• When you need lightweight stories for a team already fluent in user story format.
• When the work is purely technical with no direct user-facing situation.

Clarify First

Before writing job stories, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• Situation / trigger — the "When" anchors the entire story; a vague situation produces a persona-style story in disguise
• Underlying job & motivation — the functional/social/emotional job behind the "I want to"; without it the story encodes a solution, not a need
• Desired outcome / progress — the "so I can" the user is trying to reach; drives the outcome-focused acceptance criteria
• Source of user research — interviews/observation/support data vs guesswork; without grounding, situations get invented and may not reflect reality

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Quick Start