Provides MoSCoW, Kano Model, WSJF, and Wiegers' matrix for prioritizing requirements by business value, customer impact, effort, and risk. Includes scoring templates and trade-off analysis.
npx claudepluginhub melodic-software/claude-code-plugins --plugin requirements-elicitationThis skill is limited to using the following tools:
Comprehensive guide to prioritization techniques for requirements and features.
Ranks requirements from synthesis files using MoSCoW, Kano, WSJF, Wiegers, or opportunity methods. Outputs categorized or scored lists with justifications, optionally interactive.
Ranks requirements, features, backlog items, and initiatives using MoSCoW, Kano model, weighted scoring, and value-effort matrices.
Applies RICE, MoSCoW, Kano, ICE, Opportunity Scoring frameworks to rank features and backlog items. Use for prioritizing what to build next, backlog grooming, or tradeoff evaluation.
Share bugs, ideas, or general feedback.
Comprehensive guide to prioritization techniques for requirements and features.
Keywords: prioritization, priority, MoSCoW, Kano model, WSJF, weighted shortest job first, value cost risk, Wiegers, priority matrix, must have should have, delighters, basic needs, performance features, cost of delay
Use this skill when:
| Method | Best For | Complexity | Stakeholder Input |
|---|---|---|---|
| MoSCoW | Quick categorization, MVP scope | Low | Low |
| Kano Model | Customer satisfaction analysis | Medium | High (surveys) |
| WSJF | Agile/SAFe environments, flow optimization | Medium | Medium |
| Wiegers' Matrix | Quantitative value/cost analysis | High | Medium |
| Opportunity Scoring | JTBD-aligned prioritization | Medium | High (surveys) |
moscow:
must:
definition: "Non-negotiable for this release"
criteria:
- "System won't work without it"
- "Legal/regulatory requirement"
- "Core to value proposition"
typical_percentage: "60% of effort"
should:
definition: "Important but not critical"
criteria:
- "Significant value, but workarounds exist"
- "Key stakeholder expectations"
- "Competitive parity"
typical_percentage: "20% of effort"
could:
definition: "Nice to have if time permits"
criteria:
- "Enhances user experience"
- "Low effort, incremental value"
- "Differentiator but not essential"
typical_percentage: "20% of effort"
wont:
definition: "Explicitly out of scope for now"
criteria:
- "Agreed to defer, not rejected"
- "Future consideration"
- "Resource constraints"
note: "Document for future reference"
moscow_process:
1. List all requirements
2. Start with MUST - be strict (if everything is MUST, nothing is)
3. Move to WON'T - explicitly exclude
4. Distribute remaining between SHOULD and COULD
5. Validate: MUSTs should be ~60% of capacity
warning_signs:
- "All requirements are MUST" → Be stricter
- "No WON'Ts" → You're avoiding hard decisions
- "MUSTs exceed capacity" → Re-evaluate or reduce scope
kano_categories:
basic:
name: "Basic (Must-Be)"
description: "Expected features - absence causes dissatisfaction"
examples:
- "Website loads without errors"
- "Login works correctly"
- "Data is saved reliably"
satisfaction_curve: "Only prevents dissatisfaction, doesn't create satisfaction"
performance:
name: "Performance (One-Dimensional)"
description: "More is better - linear satisfaction"
examples:
- "Page load speed"
- "Storage capacity"
- "Number of integrations"
satisfaction_curve: "Linear relationship to investment"
excitement:
name: "Excitement (Delighters)"
description: "Unexpected features that create delight"
examples:
- "AI-powered suggestions"
- "Personalized experience"
- "Innovative shortcuts"
satisfaction_curve: "High satisfaction, low expectation"
indifferent:
name: "Indifferent"
description: "Features users don't care about"
examples:
- "Technical implementation details"
- "Over-engineered features"
action: "Deprioritize or remove"
reverse:
name: "Reverse"
description: "Features some users actively dislike"
examples:
- "Mandatory tutorials"
- "Intrusive notifications"
action: "Make optional or remove"
kano_survey:
question_pair:
functional: "How would you feel if [feature] was present?"
dysfunctional: "How would you feel if [feature] was absent?"
answer_options:
- "I would like it"
- "I expect it"
- "I'm neutral"
- "I can tolerate it"
- "I dislike it"
interpretation_matrix:
# Functional → Dysfunctional → Category
"Like → Dislike": "Excitement"
"Like → Neutral": "Excitement"
"Expect → Dislike": "Basic"
"Neutral → Neutral": "Indifferent"
"Like → Like": "Questionable (inconsistent)"
SATISFACTION
↑
│ ╱ Excitement (Delighters)
│ ╱
│ ╱
│ ╱
────┼─────────────── Performance
│ ╲
│ ╲
│ ╲
│ ╲ Basic (Must-Be)
│
└─────────────────────────────→ FULFILLMENT
Not implemented Fully implemented
wsjf:
formula: "WSJF = Cost of Delay / Job Size"
cost_of_delay:
components:
user_value: "Value to end users/customers"
time_criticality: "How much value decays with time"
risk_reduction: "Risk/opportunity enabled by feature"
formula: "CoD = User Value + Time Criticality + Risk Reduction"
job_size:
definition: "Relative effort to implement"
scale: "Fibonacci (1, 2, 3, 5, 8, 13)"
wsjf_example:
feature: "Mobile App Offline Mode"
cost_of_delay:
user_value:
score: 8
rationale: "Highly requested by field workers"
time_criticality:
score: 5
rationale: "Competitor launching similar feature in Q2"
risk_reduction:
score: 3
rationale: "Reduces support tickets for connectivity issues"
total_cod: 16
job_size:
score: 5
rationale: "Moderate complexity, known patterns"
wsjf_score: 3.2 # 16 / 5
interpretation: "High priority - good value for effort"
| Feature | User Value | Time Crit | Risk Reduction | CoD | Size | WSJF | Rank |
|---|---|---|---|---|---|---|---|
| Offline Mode | 8 | 5 | 3 | 16 | 5 | 3.2 | 1 |
| Dark Theme | 5 | 1 | 1 | 7 | 2 | 3.5 | 2 |
| Export PDF | 6 | 3 | 2 | 11 | 8 | 1.4 | 3 |
wiegers_method:
dimensions:
value:
question: "What relative benefit does this provide?"
scale: 1-9
perspective: "Customer/business value"
penalty:
question: "What's the relative penalty of NOT having this?"
scale: 1-9
perspective: "Risk of omission"
cost:
question: "What's the relative cost to implement?"
scale: 1-9
perspective: "Development effort"
risk:
question: "What's the relative technical risk?"
scale: 1-9
perspective: "Uncertainty, complexity"
formula: |
Priority = (Value × ValueWeight + Penalty × PenaltyWeight) /
(Cost × CostWeight + Risk × RiskWeight)
default_weights:
value: 2
penalty: 1
cost: 1
risk: 0.5
wiegers_example:
feature: "Two-Factor Authentication"
scores:
value: 7 # High security value
penalty: 9 # Major penalty if missing (compliance risk)
cost: 5 # Moderate implementation effort
risk: 3 # Known patterns, low risk
calculation:
numerator: (7 × 2) + (9 × 1) = 23
denominator: (5 × 1) + (3 × 0.5) = 6.5
priority: 3.54
interpretation: "High priority due to strong penalty for omission"
From the JTBD framework:
opportunity_scoring:
formula: "Opportunity = Importance + (Importance - Satisfaction)"
data_collection:
survey_questions:
importance: "How important is it to [outcome]? (1-10)"
satisfaction: "How satisfied are you with current ability? (1-10)"
interpretation:
score_15_20: "High opportunity - underserved"
score_10_15: "Moderate opportunity"
score_5_10: "Low opportunity - well served"
score_below_5: "Over-served - deprioritize"
example:
outcome: "Quickly find relevant products"
importance: 9
satisfaction: 4
score: 14 # 9 + (9-4)
interpretation: "Moderate-high opportunity"
method_selection:
use_moscow_when:
- "Quick decisions needed"
- "Stakeholders familiar with method"
- "Defining MVP scope"
- "Binary in/out decisions"
use_kano_when:
- "Understanding customer satisfaction drivers"
- "Product differentiation focus"
- "Have access to customer surveys"
- "Balancing basic vs delighter features"
use_wsjf_when:
- "Agile/SAFe environment"
- "Flow-based delivery"
- "Economic decision-making"
- "Comparing features of varying sizes"
use_wiegers_when:
- "Need quantitative justification"
- "Multiple stakeholder perspectives"
- "High-stakes prioritization decisions"
- "Want to weight multiple factors"
use_opportunity_when:
- "JTBD-based product development"
- "Customer research available"
- "Finding underserved needs"
- "Outcome-focused roadmap"
combined_approach:
step_1: "Use MoSCoW for initial categorization"
step_2: "Apply Kano to understand SHOULD/COULD items better"
step_3: "Use WSJF or Wiegers to rank within categories"
step_4: "Validate with Opportunity Scoring against customer data"
example_workflow:
- "All MUSTs go to backlog (non-negotiable)"
- "Kano analysis on SHOULDs reveals 3 delighters"
- "WSJF ranking of delighters prioritizes by value/effort"
- "Final backlog ordered with business justification"
priority_report:
domain: "{domain}"
method: "{method used}"
date: "{ISO-8601}"
summary:
total_requirements: 25
high_priority: 8
medium_priority: 10
low_priority: 7
detailed_ranking:
- rank: 1
requirement_id: "REQ-001"
title: "Two-Factor Authentication"
method_score: 3.54
rationale: "High penalty for omission, compliance requirement"
- rank: 2
requirement_id: "REQ-015"
title: "Mobile Offline Mode"
method_score: 3.2
rationale: "High user value, competitive pressure"
visualization: |
[Mermaid or ASCII chart showing priority distribution]
recommendations:
- "Immediate focus on top 5 high-priority items"
- "Consider deferring low-priority items with high cost"
- "Re-evaluate in 2 weeks based on new information"
/prioritize - Apply prioritization methods to requirements/gaps - Identify missing requirements before prioritizing/export - Export prioritized requirementsFor detailed guidance:
External:
Last Updated: 2025-12-26