Why-What-Acceptance Backlog Expert

Why-What-Acceptance Backlog Expert

Overview

Create backlog items using the Why-What-Acceptance (WWAS) format. This format ensures every piece of work connects to strategic context, includes a concise description that serves as a "reminder of the discussion" rather than a detailed specification, and defines high-level acceptance criteria focused on observable outcomes.

The format has three parts:

• Why (1-2 sentences): connects the item to a business objective, OKR, or theme; answers "why does this matter?" and "why now?" If you cannot write a compelling Why, the item should not be prioritized.
• What (1-2 paragraphs): a reminder of the refinement discussion, not a specification. Link the design if one exists.
• Acceptance Criteria (4+): observable outcomes that define done — not implementation steps or test scripts.

Before an item enters a sprint, it must pass the INVEST gates (Independent, Negotiable, Valuable, Estimable, Small, Testable).

When to Use

• Backlog creation -- building a product backlog where strategic alignment is critical.
• Sprint planning -- refining items and the team needs to understand why each matters.
• Stakeholder communication -- executives need to see how work connects to business objectives.
• Roadmap decomposition -- breaking roadmap themes into actionable backlog items.

When NOT to Use

• When you need situation-driven requirements -- use job-stories/ instead.
• A pure technical task with no strategic context (use a simple task description).
• The team prefers traditional user stories and strategic context is well-understood.

Clarify First

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

• The strategic objective / OKR it connects to — drives the Why; without it the Why is a forced exercise and the item should not be prioritized
• The refinement discussion or design link — becomes the What (a reminder of the discussion, not a specification)
• The observable done-state — drives the Acceptance Criteria (outcomes a user or system can observe, not implementation steps or test scripts)

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.

References

Load the reference that matches the task; keep this file lean and pull detail on demand.