# User Stories vs Job Stories vs WWAS: Choosing the Right Backlog Format > Compare user stories job stories and WWAS agile backlog formats. Understand their core differences and choose the best fit for your projects to enhance clarity and drive results. - Repository: [Pawel Huryn/pm-skills](https://github.com/phuryn/pm-skills) - Tags: tutorial - Published: 2026-06-13 --- **The pm-skills repository provides three distinct backlog formats: Job Stories focus on situational context and Jobs-to-be-Done, User Stories emphasize role-based requirements and INVEST criteria, and WWAS (Why-What-Acceptance) blends strategic rationale with concise deliverables.** The `phuryn/pm-skills` repository defines three specialized formats for capturing product requirements in the `pm-execution` package. Understanding the architectural differences between user stories, job stories, and WWAS formats ensures you select the right structure for your team's workflow and product philosophy. ## Format Structure and Design Philosophy Each format in the pm-skills codebase serves a distinct product-management philosophy, implemented through dedicated skill files under `pm-execution/skills/`. ### Job Stories **Job Stories** use the template: `When [situation], I want [motivation], so I can [outcome]`. This format, defined in [`pm-execution/skills/job-stories/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/pm-execution/skills/job-stories/SKILL.md), emphasizes the **context** that triggers a user need rather than the user role. It applies **Jobs-to-be-Done (JTBD)** thinking, making it ideal for research-driven teams where the "job" matters more than the persona. The structure captures the circumstance, motivation, and desired outcome in a continuous narrative. ### User Stories **User Stories** follow the classic: `As a [user role], I want [capability], so that [benefit]`. Implemented in [`pm-execution/skills/user-stories/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/pm-execution/skills/user-stories/SKILL.md), this format centers on the **user role** and the **value** received. It enforces the **3 Cs** (Card, Conversation, Confirmation) and **INVEST** qualities (Independent, Negotiable, Valuable, Estimable, Small, Testable). This is the standard for traditional Scrum or Kanban teams mapping features to specific personas. ### WWAS (Why-What-Acceptance) **WWAS** structures requirements as: **Why** (strategic context) → **What** (deliverable description) → **Acceptance** (high-level criteria). Stored in [`pm-execution/skills/wwas/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/pm-execution/skills/wwas/SKILL.md), this format surfaces **business intent** alongside technical delivery. It keeps backlog items independent and testable without over-specifying, making it optimal for cross-functional teams needing lightweight, strategic visibility during road-mapping or quick triage sessions. ## Technical Implementation and Command Architecture All three formats are generated through the unified `/write-stories` command, implemented in [`pm-execution/commands/write-stories.md`](https://github.com/phuryn/pm-skills/blob/main/pm-execution/commands/write-stories.md). The command follows a four-stage architectural flow: 1. **Invocation** – Run `/write-stories ` (valid format tokens: `user`, `job`, `wwa`) 2. **Skill Selection** – The command loads the corresponding skill file based on the format token 3. **Template Rendering** – The skill defines a markdown template with title, description, design links, and acceptance criteria 4. **Output** – Returns a ready-to-use backlog section saveable as Markdown The command automatically appends acceptance criteria, design links, and optional next-step prompts regardless of which format you select. ## When to Use Each Format Select your format based on team workflow and information needs: - **Job Stories** – Choose when designing around real-world situations where the trigger context matters more than the user persona. Best for JTBD-oriented discovery. - **User Stories** – Choose for traditional agile teams requiring clear role-based requirements and strict INVEST compliance. - **WWAS** – Choose when you must surface strategic rationale (the "Why") alongside the work for stakeholders who need business context without verbose specifications. ## Generating Stories: Practical Examples Use these commands in the pm-skills interface to generate each format. ### Job Story Example ```bash /write-stories job When users view a pricing page, I want a clear cost‑breakdown, so I can decide which plan fits my budget ``` **Output:** ```markdown **Title:** Clear Cost‑Breakdown on Pricing Page Description: When users view a pricing page (situation), I want a clear cost‑breakdown (motivation), so I can decide which plan fits my budget (outcome). Design: [Link to Figma design] Acceptance Criteria: 1. The cost‑breakdown section appears above the “Choose Plan” button. 2. All pricing tiers display monthly and annual costs. 3. A tooltip explains any hidden fees. ... ``` ### User Story Example ```bash /write-stories user As a marketing analyst, I want to export campaign data as CSV, so that I can perform offline analysis in Excel ``` **Output:** ```markdown **Title:** Export Campaign Data Description: As a marketing analyst, I want to export campaign data as CSV, so that I can perform offline analysis in Excel. Design: [Link to design mockup] Acceptance Criteria: 1. Export button is visible on the campaign dashboard. 2. Exported file contains campaign ID, spend, impressions, and click‑through rate. 3. CSV adheres to RFC 4180 format. ... ``` ### WWAS Example ```bash /write-stories wwa Dark mode for the mobile app ``` **Output:** ```markdown **Title:** Dark Mode for Mobile App Why: Users frequently report eye‑strain during night usage; enabling a dark UI aligns with our accessibility goals and improves engagement metrics. What: Add a toggle in the Settings screen that switches the app theme to a dark palette. Design specs are in [Figma link]. Acceptance Criteria: - Theme changes instantly after toggle. - All primary UI components respect the dark color tokens. - No regression in contrast ratios for WCAG AA. ... ``` ## Summary - **Job Stories** ([`pm-execution/skills/job-stories/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/pm-execution/skills/job-stories/SKILL.md)) capture situational context using the "When-I want-so I can" structure, prioritizing JTBD over personas. - **User Stories** ([`pm-execution/skills/user-stories/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/pm-execution/skills/user-stories/SKILL.md)) enforce role-based requirements with INVEST criteria through the "As a-I want-so that" template. - **WWAS** ([`pm-execution/skills/wwas/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/pm-execution/skills/wwas/SKILL.md)) provides strategic alignment via Why-What-Acceptance sections, ideal for cross-functional visibility. - All formats are accessible via the `/write-stories` command in [`pm-execution/commands/write-stories.md`](https://github.com/phuryn/pm-skills/blob/main/pm-execution/commands/write-stories.md), which delegates to the appropriate skill template based on the format token provided. ## Frequently Asked Questions ### What is the primary difference between Job Stories and User Stories? Job Stories focus on the **situation** and motivation driving a behavior, using the format "When [situation], I want [motivation], so I can [outcome]." User Stories focus on the **persona** and capability, using "As a [role], I want [capability], so that [benefit]." Use Job Stories when the triggering context matters more than who triggers it. ### When should teams use the WWAS format instead of traditional User Stories? Use the **WWAS** (Why-What-Acceptance) format when you need to surface **strategic rationale** alongside the deliverable. This format excels in cross-functional environments where business stakeholders require immediate visibility into the "Why" behind a backlog item without reading through persona-based narratives. ### How does the pm-skills repository generate these different formats? The `/write-stories` command in [`pm-execution/commands/write-stories.md`](https://github.com/phuryn/pm-skills/blob/main/pm-execution/commands/write-stories.md) acts as a router. It accepts a format token (`user`, `job`, or `wwa`) and loads the corresponding skill definition from `pm-execution/skills/`, rendering the appropriate template with acceptance criteria and design placeholders. ### Can I customize the templates for my organization's specific needs? Yes. Since each format is defined in standalone skill files ([`job-stories/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/job-stories/SKILL.md), [`user-stories/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/user-stories/SKILL.md), [`wwas/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/wwas/SKILL.md)), you can modify the markdown templates, acceptance criteria defaults, or add custom fields while preserving the shared `/write-stories` command interface.