Difference Between User Stories, Job Stories, and WWAS Formats: A Product Management Guide

Job Stories emphasize situational context using Jobs-to-Be-Done principles, User Stories focus on user roles and INVEST criteria, and the WWAS (Why-What-Acceptance) format blends strategic rationale with deliverable descriptions for cross-functional alignment.

The phuryn/pm-skills repository provides three distinct backlog item formats, each architected for specific product management philosophies and team workflows. Understanding these structural differences helps you select the right template for research-driven discovery, traditional Scrum execution, or strategic roadmap planning.

Format Architecture and Philosophy

Job Stories: Context-Driven JTBD

Job Stories prioritize the situation that triggers a user need rather than the user’s identity. According to the template defined in pm-execution/skills/job-stories/SKILL.md, this format follows the structure: When [situation], I want [motivation], so I can [outcome].

This approach emphasizes Jobs-to-Be-Done (JTBD) thinking, making it ideal for research-driven teams who design around real-world scenarios. Choose this format when the circumstance matters more than the persona, such as when users across different roles face identical constraints.

User Stories: Role-Based INVEST

User Stories anchor requirements to specific personas using the classic structure: As a [user role], I want [capability], so that [benefit]. The template in pm-execution/skills/user-stories/SKILL.md enforces the 3 C’s (Card, Conversation, Confirmation) and INVEST qualities (Independent, Negotiable, Valuable, Estimable, Small, Testable).

This format works best for traditional Scrum or Kanban teams that map features to defined user personas. It creates clear, role-based requirements that facilitate estimation and sprint planning.

WWAS: Strategic Alignment

The WWAS (Why-What-Acceptance) format, defined in pm-execution/skills/wwas/SKILL.md, structures backlog items into three sections: Why (strategic context), What (deliverable description), and Acceptance (high-level criteria).

This format keeps items independent, valuable, and testable without over-specifying implementation. It excels in cross-functional environments where business stakeholders must quickly triage items against strategic goals during roadmap planning.

Command Implementation in pm-skills

All three formats execute through the same command-level entry point: /write-stories. The implementation in pm-execution/commands/write-stories.md handles format selection and template rendering through a consistent skill-delegation pattern.

The architectural flow follows three steps:

1. Invocation: Run /write-stories <format> <feature description>, where <format> accepts the tokens job, user, or wwa.
2. Skill Selection: The command loads the corresponding skill file (job-stories, user-stories, or wwas) based on the format token.
3. Template Rendering: The selected skill returns a markdown template containing the title, description, design links, and acceptance criteria.

The command automatically appends acceptance criteria, design placeholders, and optional next-step prompts regardless of which format you select.

Practical Usage Examples

Below are concrete commands you can execute 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

Generated 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

Generated 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

Generated 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) use the When... I want... so I can... structure to capture situational context and JTBD motivations.
• User Stories (pm-execution/skills/user-stories/SKILL.md) employ As a... I want... so that... syntax to enforce role-based INVEST criteria and persona alignment.
• WWAS (pm-execution/skills/wwas/SKILL.md) organizes items into Why-What-Acceptance sections to surface strategic business intent alongside deliverables.
• All formats are accessible via the /write-stories command in pm-execution/commands/write-stories.md, which delegates to the appropriate skill based on the job, user, or wwa format token.

Frequently Asked Questions

When should I use Job Stories instead of User Stories?

Use Job Stories when the triggering situation matters more than the user’s demographic or role, such as when multiple personas encounter the same constraint (e.g., "When I’m on a flight with no wifi..."). Use User Stories when you need to trace specific features back to defined personas and enforce INVEST qualities for sprint estimation.

What does the WWAS format include that User Stories do not?

The WWAS format explicitly separates strategic Why statements from implementation What descriptions, making it easier for cross-functional teams to validate business value before committing to delivery. Standard User Stories embed the benefit in the "so that" clause but do not require the formal Why-What-Acceptance structure that WWAS enforces.

How do I invoke the different formats in pm-skills?

Invoke any format using the /write-stories command followed by the format token and description. Use job for Job Stories, user for User Stories, and wwa for WWAS. For example: /write-stories user As a... or /write-stories wwa Feature description.

Can I customize the templates in the pm-skills repository?

Yes. The templates live in their respective skill files under pm-execution/skills/job-stories/SKILL.md, user-stories/SKILL.md, and wwas/SKILL.md. You can modify the markdown templates and acceptance criteria defaults while preserving the shared command interface in pm-execution/commands/write-stories.md.

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