Helps structure backlog items into clear, testable Why-What-Acceptance statements.
Install
mkdir -p .claude/skills/wwas && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/12795" && unzip -o skill.zip -d .claude/skills/wwas && rm skill.zipInstalls to .claude/skills/wwas
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Create product backlog items in Why-What-Acceptance format — independent, valuable, testable items with strategic context. Use when writing structured backlog items, breaking features into work items, or using the WWA format.Key capabilities
- →Define the strategic Why for backlog items
- →Describe the What for product increments
- →Write Acceptance Criteria for features
- →Ensure independence of work items
- →Make items valuable for users or business
- →Size items for one sprint estimate
How it works
This skill generates product backlog items by following a structured template that includes sections for Why, What, and Acceptance Criteria, ensuring each item connects to strategic context.
Inputs & outputs
When to use wwas
- →Write user stories
- →Define backlog items
- →Structure feature requirements
About this skill
Why-What-Acceptance (WWA)
Create product backlog items in Why-What-Acceptance format. Produces independent, valuable, testable items with strategic context.
Use when: Writing backlog items, creating product increments, breaking features into work items, or communicating strategic intent to teams.
Arguments:
$PRODUCT: The product or system name$FEATURE: The new feature or capability$DESIGN: Link to design files (Figma, Miro, etc.)$ASSUMPTIONS: Key assumptions and strategic context
Step-by-Step Process
- Define the strategic Why - Connect work to business and team objectives
- Describe the What - Keep descriptions concise, reference designs
- Write Acceptance Criteria - High-level, not detailed specifications
- Ensure independence - Items can be developed in any order
- Keep items negotiable - Invite team conversation, not constraints
- Make items valuable - Each delivers measurable user or business value
- Ensure testability - Outcomes are observable and verifiable
- Size appropriately - Small enough for one sprint estimate
Item Template
Title: [What will be delivered]
Why: [1-2 sentences connecting to strategic context and team objectives]
What: [Short description and design link. 1-2 paragraphs maximum. A reminder of discussion, not detailed specification.]
Acceptance Criteria:
- [Observable outcome 1]
- [Observable outcome 2]
- [Observable outcome 3]
- [Observable outcome 4]
Example WWA Item
Title: Implement Real-Time Spending Tracker
Why: Users need immediate feedback on spending to make conscious budget decisions. This directly supports our goal to improve financial awareness and reduce overspending.
What: Add a real-time spending tracker that updates as users log expenses. The tracker displays their current week's spending against their set budget. Designs available in [Figma link]. This is a reminder of our discussions - detailed specifications will emerge during development conversations with the team.
Acceptance Criteria:
- Spending totals update within 2 seconds of logging an expense
- Budget progress is visually indicated with a progress bar
- Users can see remaining budget amount at a glance
- System handles multiple expense categories correctly
Output Deliverables
- Complete set of backlog items for the feature
- Each item includes Why, What, and Acceptance Criteria sections
- Items are independent and deliverable in any order
- Items are sized for estimation and completion in one sprint
- Strategic context is clear for team decision-making
- Design references are included for implementation guidance
Further Reading
When not to use it
- →When detailed specifications are required
- →When items are not independent
- →When items are not testable
Limitations
- →Acceptance Criteria are high-level, not detailed specifications
- →The output is a reminder of discussion, not detailed specification
- →Items are negotiable and invite team conversation
How it compares
This workflow structures backlog items with explicit strategic context and testable criteria, unlike a generic approach that might lack these defined sections.
Compared to similar skills
wwas side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| wwas (this skill) | 0 | 5mo | No flags | Beginner |
| launch-strategy | 4 | 6mo | No flags | Beginner |
| prd-drafter | 1 | 6mo | No flags | Beginner |
| story | 0 | 2mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
launch-strategy
davila7
When the user wants to plan a product launch, feature announcement, or release strategy. Also use when the user mentions 'launch,' 'Product Hunt,' 'feature release,' 'announcement,' 'go-to-market,' 'beta launch,' 'early access,' 'waitlist,' or 'product update.' This skill covers phased launches, channel strategy, and ongoing launch momentum.
prd-drafter
galz10
Pickle Rick's PRD Engine. Use when you need to define the requirements, scope, and goals for a new feature or project before coding to avoid "Jerry-work."
story
matteocervelli
Turn a feature idea into INVEST-compliant user stories, epics, PRPs/PRDs, and sprint plans. Use when breaking down a feature for implementation or planning a sprint. Trigger on "write user stories", "break this into stories", "create a PRP", "plan the sprint", "story".
prd
alfredolopez80
Product Requirements Document generation and management with INVEST-compliant user stories
reversa-drafter
stribus
Agente Drafter do time Code New Project Agents. Sintetiza `ideation.md` e `personas.md` em um PRD completo (problema, métricas, escopo, não-objetivos, restrições, riscos). Use quando o usuário digitar "/reversa-drafter", "reversa-drafter" ou quando invocado pelo orquestrador `/reversa-new`. Produz `
speckit-specify
MasterYXiao
Create or update feature specifications from natural-language requests for this Spec Kit workflow. Use when starting a new feature or re-baselining spec.md before clarify/plan.