backlog-prioritization

name	backlog-prioritization
description	MoSCoW, value vs. effort, dependency sequencing, and trade-off documentation for backlog management. Use when stack-ranking a feature backlog, managing capacity constraints, or documenting prioritization rationale.

Backlog Prioritization

Backlog prioritization is about making the cost of trade-offs visible. When every item is a priority, nothing is. This skill covers the frameworks for stack-ranking a backlog, managing dependencies, and documenting the rationale clearly enough that decisions can be revisited without re-litigating from scratch.

When to Use This Skill

• Stack-ranking a feature backlog before a cycle begins
• Cutting scope when capacity is less than the backlog
• Resolving dependency conflicts in sequencing
• Communicating prioritization rationale to stakeholders
• Reviewing an existing backlog for hidden assumptions or missing trade-offs

MoSCoW Framework

MoSCoW categorizes every item into one of four tiers:

Tier	Definition	Rule
Must Have	Launch-blocking. Without this, the cycle fails.	If everything is Must Have, the scope is wrong.
Should Have	High value, strong preference, but not blocking.	Cut last. Recover in the next cycle if needed.
Could Have	Nice to have. Worth doing if capacity allows.	Cut first when capacity is tight.
Won't Have (this cycle)	Explicitly deferred. Not forgotten, not relevant now.	Documenting Won't Have is as important as the other tiers.

Calibrating Must Have

Must Have should represent no more than 60% of estimated capacity. If Must Have exceeds capacity, you have a scope problem — not a capacity problem. The fix is to reclassify items, not to ask for more time.

Capacity: 10 person-weeks
Must Have total: 8 person-weeks ← OK
Must Have total: 14 person-weeks ← Must reclassify; scope is broken

Value vs. Effort Quadrant

Plot every backlog item on a 2×2:

              High Value
                  │
   Quick Wins     │    Major Projects
   (Do First)     │    (Plan Carefully)
                  │
Low Effort ───────┼─────────── High Effort
                  │
    Fill-ins      │    Money Pits
    (Do if time)  │    (Avoid or Re-scope)
                  │
              Low Value

• Quick Wins: High value, low effort — do these first, they fund the rest
• Major Projects: High value, high effort — sequence carefully; require strong evidence before committing
• Fill-ins: Low value, low effort — do only if you have spare capacity at end of cycle
• Money Pits: Low value, high effort — cut these entirely; demand re-scope or strong strategic justification

Dependency Sequencing

Dependency Graph

Map dependencies before sequencing. A depends on B means B must ship before A is useful or buildable.

A → B → D
      ↘ E
C → F

In this graph: B must precede D and E; A must precede B; C must precede F. D and F can be done in parallel once their predecessors ship.

Dependency Sequencing Rules

1. Hard dependencies: Feature A literally cannot be built without Feature B. B goes first, regardless of relative RICE scores.
2. Value dependencies: Feature A can be built but delivers no value without Feature B. B should go first unless A can be validated independently.
3. Soft dependencies: Feature A is better with Feature B but works standalone. Can sequence in either order.

Dependency Risk Assessment

For each dependency:

Feature: [A]
Depends on: [B]
Dependency type: Hard / Value / Soft
Risk: What happens if B is delayed or descoped?
Mitigation: [How A can be de-risked from B's delay]

Trade-off Documentation

Every prioritization decision is a trade-off. Documenting the trade-off makes it:

• Reversible when circumstances change
• Defensible when stakeholders question it
• Learnable when the decision turns out to be wrong

Trade-off Template

Decision: [Feature X is prioritized above Feature Y]

Rationale:
- Feature X has higher RICE score (24K vs. 8K)
- Feature X is a prerequisite for Feature Z in the next cycle
- Feature Y can be deferred without competitive risk (not in competitor products yet)

What we're giving up:
- Feature Y addresses a segment (power users) who have asked for it repeatedly
- Deferring Feature Y increases churn risk for this segment by an estimated 5%

Conditions for reversal:
- If churn in the power user segment exceeds X% before next cycle, re-evaluate

Capacity-Aware Scoping

Scoping Process

1. Establish velocity baseline: Average person-weeks per cycle from last 3 cycles
2. Apply uncertainty buffer: Reduce by 20% for sprint overhead, bugs, and surprises
3. Stack rank the backlog: Use RICE or a weighted scoring model
4. Draw the line: Items above the line are in scope; items below are deferred
5. Validate Must Haves: Confirm Must Haves fit within 60% of capacity

Capacity Buffer Guidelines

Cycle Characteristics	Buffer
Well-understood work, familiar codebase	15%
Mixed new and familiar work	20%
Significant new technology or architecture	30%
High external dependencies	25%

When the Backlog Exceeds Capacity

Options, in order of preference:

1. Reclassify Must Haves — are they truly blocking, or just strongly preferred?
2. Split features — can a feature be shipped in a smaller form first?
3. Reduce scope per feature — what's the minimum viable version of each Must Have?
4. Push to next cycle — which Should Haves can wait without significant cost?
5. Extend timeline — only if there's a genuine hard dependency on the date (rare)

Communicating Prioritization

Stack-Ranked Backlog Format

# Cycle Backlog: [Cycle Name]

Capacity: [X person-weeks]
Must Have: [Y person-weeks — Z% of capacity]
Should Have: [Y person-weeks]
Could Have: [Y person-weeks]

## Must Have (launches this cycle)

| # | Feature | RICE Score | Effort | Rationale |
|---|---------|-----------|--------|-----------|
| 1 | [Feature] | [Score] | [Weeks] | [Why #1] |

## Should Have

| # | Feature | RICE Score | Effort | Why Deferred from Must Have |
|---|---------|-----------|--------|----------------------------|

## Won't Have This Cycle

| Feature | Reason | Next Review |
|---------|--------|-------------|
| [Feature] | [Why deferred] | [When to revisit] |

Best Practices

1. Every ranking decision has a written rationale — "feels right" is not a rationale
2. Force the hard choices — if the stakeholder says everything is P0, run them through the MoSCoW calibration exercise
3. Document Won't Haves explicitly — deferred items without documentation get re-litigated in every planning session
4. Track backlog age — items that have been deferred for 3+ cycles should either be committed to or permanently removed
5. Revisit after major evidence changes — a new competitive threat or a significant research finding should trigger a re-ranking, not just a note