RICE, MoSCoW, Kano, and value-effort prioritization frameworks with scoring methodologies and decision documentation. Use when prioritizing features, evaluating competing initiatives, creating roadmaps, or making build vs defer decisions.
/plugin marketplace add rsmdt/the-startup/plugin install team@the-startupThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Systematic frameworks for making objective prioritization decisions that balance value, effort, and strategic alignment.
Quantitative scoring for comparing initiatives objectively.
RICE Score = (Reach × Impact × Confidence) / Effort
| Factor | Description | Scale |
|---|---|---|
| Reach | How many users affected per quarter | Actual number (100, 1000, 10000) |
| Impact | Effect on each user | 0.25 (Minimal) to 3 (Massive) |
| Confidence | How sure are we | 50% (Low) to 100% (High) |
| Effort | Person-months required | Actual estimate (0.5, 1, 3, 6) |
| Score | Label | Description |
|---|---|---|
| 3 | Massive | Life-changing for users, core workflow transformation |
| 2 | High | Major improvement, significant time savings |
| 1 | Medium | Noticeable improvement, minor friction reduction |
| 0.5 | Low | Slight improvement, nice-to-have |
| 0.25 | Minimal | Barely noticeable difference |
| Score | Label | Basis |
|---|---|---|
| 100% | High | User research + validated data + successful tests |
| 80% | Medium | Some data + team experience + analogous examples |
| 50% | Low | Intuition only, no supporting data |
Feature: One-click reorder
Reach: 5,000 (customers who reorder monthly)
Impact: 2 (High - saves significant time)
Confidence: 80% (Based on support ticket analysis)
Effort: 1 person-month
RICE = (5000 × 2 × 0.8) / 1 = 8000
Feature: Dark mode
Reach: 20,000 (all active users)
Impact: 0.5 (Low - preference, not productivity)
Confidence: 50% (No data, user requests only)
Effort: 2 person-months
RICE = (20000 × 0.5 × 0.5) / 2 = 2500
Decision: One-click reorder scores higher, prioritize first
| Feature | Reach | Impact | Confidence | Effort | Score | Rank |
|---|---|---|---|---|---|---|
| Feature A | 5000 | 2 | 80% | 1 | 8000 | 1 |
| Feature B | 20000 | 0.5 | 50% | 2 | 2500 | 2 |
Visual framework for quick categorization.
High Value
│
┌──────────────┼──────────────┐
│ │ │
│ QUICK WINS │ STRATEGIC │
│ Do First │ Plan & Do │
│ │ │
├──────────────┼──────────────┤ High
Low │ │ │ Effort
Effort │ │
│ FILL-INS │ TIME SINKS │
│ If Spare │ Avoid │
│ Capacity │ │
│ │ │
└──────────────┼──────────────┘
│
Low Value
| Quadrant | Characteristics | Action |
|---|---|---|
| Quick Wins | High value, low effort | Do immediately |
| Strategic | High value, high effort | Plan carefully, staff appropriately |
| Fill-Ins | Low value, low effort | Do when nothing else is ready |
| Time Sinks | Low value, high effort | Don't do (or simplify drastically) |
Value Assessment:
Effort Assessment:
Categorize features by their impact on satisfaction.
Satisfaction
▲
│ ╱ Delighters
│ ╱ (Unexpected features)
│ ╱
─────┼────●──────────────────────────► Feature
│ │╲ Implementation
│ │ ╲ Performance
│ │ (More is better)
│ │
│ └── Must-Haves
│ (Expected, dissatisfaction if missing)
▼
| Category | Present | Absent | Example |
|---|---|---|---|
| Must-Have | Neutral | Very dissatisfied | Login functionality |
| Performance | More = better | Less = worse | Page load speed |
| Delighter | Very satisfied | Neutral | Personalized recommendations |
| Indifferent | No effect | No effect | Backend tech choice |
| Reverse | Dissatisfied | Satisfied | Forced tutorials |
For each feature, ask two questions:
Functional: "If [feature] were present, how would you feel?"
Dysfunctional: "If [feature] were absent, how would you feel?"
Answer Options:
1. I like it
2. I expect it
3. I'm neutral
4. I can tolerate it
5. I dislike it
| Like | Expect | Neutral | Tolerate | Dislike | |
|---|---|---|---|---|---|
| Like | Q | A | A | A | O |
| Expect | R | I | I | I | M |
| Neutral | R | I | I | I | M |
| Tolerate | R | I | I | I | M |
| Dislike | R | R | R | R | Q |
Key: M=Must-Have, O=One-dimensional, A=Attractive, I=Indifferent, R=Reverse, Q=Questionable
Simple categorization for scope definition.
| Category | Definition | Negotiability |
|---|---|---|
| Must | Critical for success, release blocked without | Non-negotiable |
| Should | Important but not critical | Can defer to next release |
| Could | Nice to have, minor impact | First to cut if needed |
| Won't | Explicitly excluded from scope | Not this release |
Budget Allocation (Recommended):
- Must: 60% of capacity
- Should: 20% of capacity
- Could: 20% of capacity (buffer)
- Won't: 0% (explicitly excluded)
Why the buffer matters:
- Must items often take longer than estimated
- Should items may become Must if requirements change
- Could items fill capacity at sprint end
Feature: User Registration
MUST:
✓ Email/password signup
✓ Email verification
✓ Password requirements enforcement
SHOULD:
○ Social login (Google)
○ Remember me functionality
○ Password strength indicator
COULD:
◐ Social login (Facebook, Apple)
◐ Profile picture upload
◐ Username suggestions
WON'T (this release):
✗ Two-factor authentication
✗ SSO integration
✗ Biometric login
Prioritize by economic impact of waiting.
CD3 = Cost of Delay / Duration
Cost of Delay: Weekly value lost by not having the feature
Duration: Weeks to implement
| Type | Description | Calculation |
|---|---|---|
| Revenue | Sales not captured | Lost deals × average value |
| Cost | Ongoing expenses | Weekly operational cost |
| Risk | Penalty or loss potential | Probability × impact |
| Opportunity | Market window | Revenue × time sensitivity |
Value
│
Standard: │────────────────
│
└──────────────────► Time
Urgent: │╲
│ ╲
│ ╲──────────
│
└──────────────────► Time
Deadline: │
│────────┐
│ │
│ └─ (drops to zero)
└──────────────────► Time
Feature A: New payment method
- Cost of Delay: $10,000/week (lost sales to competitor)
- Duration: 4 weeks
- CD3 = 10000 / 4 = 2500
Feature B: Admin dashboard redesign
- Cost of Delay: $2,000/week (support inefficiency)
- Duration: 2 weeks
- CD3 = 2000 / 2 = 1000
Feature C: Compliance update (deadline in 6 weeks)
- Cost of Delay: $50,000/week after deadline (fines)
- Duration: 4 weeks
- CD3 = 50000 / 4 = 12500 (if started now, 0 if after deadline)
Priority: C (deadline), then A (highest CD3), then B
Custom scoring for organization-specific criteria.
Step 1: Define Criteria
- Strategic alignment
- Revenue potential
- User demand
- Technical feasibility
- Competitive advantage
Step 2: Assign Weights (total = 100%)
| Criterion | Weight |
|-----------|--------|
| Strategic | 30% |
| Revenue | 25% |
| User demand | 20% |
| Feasibility | 15% |
| Competitive | 10% |
Step 3: Score Each Feature (1-5 scale)
| Feature | Strategic | Revenue | Demand | Feasible | Competitive | Total |
|---------|-----------|---------|--------|----------|-------------|-------|
| A | 5 | 4 | 3 | 4 | 2 | 3.95 |
| B | 3 | 5 | 5 | 3 | 3 | 3.90 |
| C | 4 | 3 | 4 | 5 | 4 | 3.85 |
Score = Σ (criterion_score × criterion_weight)
Feature A:
= (5 × 0.30) + (4 × 0.25) + (3 × 0.20) + (4 × 0.15) + (2 × 0.10)
= 1.5 + 1.0 + 0.6 + 0.6 + 0.2
= 3.9
# Priority Decision: [Feature/Initiative]
## Date: [YYYY-MM-DD]
## Decision: [Prioritize / Defer / Reject]
## Context
[What prompted this decision?]
## Evaluation
### Framework Used: [RICE / Kano / MoSCoW / Weighted]
### Scores
[Show calculations or categorization]
### Trade-offs Considered
- Option A: [description] - [pros/cons]
- Option B: [description] - [pros/cons]
## Decision Rationale
[Why this priority over alternatives?]
## Stakeholders
- Agreed: [names]
- Disagreed: [names, reasons documented]
## Review Date
[When to revisit if deferred]
| Situation | Recommended Framework |
|---|---|
| Comparing many similar features | RICE (quantitative) |
| Quick triage of backlog | Value vs Effort |
| Understanding user expectations | Kano Model |
| Defining release scope | MoSCoW |
| Time-sensitive decisions | Cost of Delay |
| Organization-specific criteria | Weighted Scoring |
| Anti-Pattern | Problem | Solution |
|---|---|---|
| HiPPO | Highest-paid person's opinion wins | Use data-driven frameworks |
| Recency Bias | Last request gets priority | Systematic evaluation of all options |
| Squeaky Wheel | Loudest stakeholder wins | Weight by strategic value |
| Analysis Paralysis | Over-analyzing decisions | Time-box evaluation |
| Sunken Cost | Continuing failed initiatives | Evaluate future value only |
| Feature Factory | Shipping without measuring | Tie features to outcomes |
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.