User Stories vs Job Stories vs WWAS: Choosing the Right Backlog Format

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, 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, 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, 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. The command follows a four-stage architectural flow:

1. Invocation – Run /write-stories <format> <feature description> (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

/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:

**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

/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:

**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

/write-stories wwa Dark mode for the mobile app

Output:

**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) 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) enforce role-based requirements with INVEST criteria through the "As a-I want-so that" template.
• WWAS (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, 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 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, user-stories/SKILL.md, wwas/SKILL.md), you can modify the markdown templates, acceptance criteria defaults, or add custom fields while preserving the shared /write-stories command interface.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}