Prioritization

Prioritization

Make better decisions about what to do first.

When to use this skill

• Scoring features or initiatives to decide quarterly priorities
• Categorizing requirements as Must/Should/Could/Won't for a release
• Creating effort-impact matrices for sprint planning
• Defending prioritization decisions to stakeholders with data
• Auditing existing prioritization for bias (HiPPO, recency, squeaky wheel)
• Choosing between RICE, ICE, MoSCoW, or effort-impact for a specific situation

When NOT to use this skill

• Defining OKRs or success metrics → use outcome-orientation
• Assessing project risks → use risk-management
• Making strategic bets under deep uncertainty → use strategic-decision workflow
• Stakeholder analysis for whose input to weight → use persona-mapping

---

Framework selection decision tree

Do you have reach data (users affected per quarter)?
  YES → Do you need quantitative rigor for stakeholder defense?
    YES → RICE (most defensible, separates reach/impact/confidence)
    NO  → Effort-Impact matrix (quick visual sort)
  NO  → Do you need release scoping with capacity constraints?
    YES → MoSCoW (60% rule prevents scope creep)
    NO  → ICE (lightweight, works with subjective scores only)

Using more than one? They complement each other:
  RICE or ICE for quarterly prioritization
  MoSCoW for release scoping
  Effort-Impact for sprint-level quick wins

---

RICE Scoring

Reach x Impact x Confidence / Effort

Factor	Description	Scale
Reach	Users affected per quarter	Number
Impact	Effect on goal	0.25-3
Confidence	Certainty level	50-100%
Effort	Person-months	Number

Score = (R x I x C) / E

Impact Scale

• 3 = Massive
• 2 = High
• 1 = Medium
• 0.5 = Low
• 0.25 = Minimal

MoSCoW Method

Priority	Meaning	Guideline
Must	Required for success	Non-negotiable
Should	Important but not vital	Include if possible
Could	Nice to have	If time permits
Won't	Not this time	Explicitly excluded

Rule: Must = 60% max of effort

ICE Scoring

Factor	Description	Scale
Impact	Potential value	1-10
Confidence	Certainty	1-10
Ease	Simplicity	1-10

Score = (I + C + E) / 3

Effort-Impact Matrix

HIGH IMPACT
     |
 BIG |  QUICK
BETS |  WINS
     |
-----+------ LOW EFFORT
     |
MONEY|  FILL
PITS |  INS
     |
LOW IMPACT

Priority order: Quick Wins -> Big Bets -> Fill Ins -> Avoid Money Pits

Prioritization Template

## Item: [Name]

### RICE Score
| Factor | Value | Notes |
|--------|-------|-------|
| Reach | [num] | [who] |
| Impact | [0.25-3] | [why] |
| Confidence | [%] | [evidence] |
| Effort | [PM] | [breakdown] |
| **Score** | [calc] | |

### Decision
Priority: [High/Med/Low]
Rationale: [reasoning]

Anti-Patterns

Common prioritization failures

1. HiPPO (Highest Paid Person's Opinion) — the most senior person's preference wins regardless of impact data. Counter: present RICE comparison data; if overridden, document the override reason explicitly.
2. Recency bias — the latest request displaces long-planned high-impact work. Counter: score every request before adding to backlog; compare new request score against current top items.
3. Squeaky wheel — the loudest customer gets prioritized, not the most impacted segment. Counter: weight by reach data, not volume of complaints.
4. Sunk cost fallacy — continuing a project because of past investment. Counter: re-score with only remaining effort and remaining impact; past investment is irrelevant to forward-looking decisions.
5. Confidence inflation — scoring 90% confidence on everything, eliminating it as a differentiator. Counter: calibrate — 90% = strong evidence (A/B test, customer data), 70% = reasonable belief, 50% = intuition only.
6. All Must-haves — MoSCoW with 15 "Must" items exceeding capacity. Counter: enforce the 60% rule; force-rank within Must and demote the lowest.
7. RICE without data — guessing all values produces opinions with math, not defensible scores. Counter: switch to ICE (designed for subjective scoring) or invest in analytics before RICE.
8. Strategic override without documentation — overriding RICE for a key account is sometimes correct, but undocumented overrides erode trust in the framework. Always write down why.