Prioritizing Backlog Items | RICE & MoSCoW Frameworks

Prioritize backlog items using RICE (Reach, Impact, Confidence, Effort) and MoSCoW frameworks. Ensure teams work on highest-value items in GitScrum.

7 min read

Backlog prioritization is where strategy meets execution. Without clear prioritization, teams work on whatever's newest or loudest rather than what's most valuable. Effective prioritization uses frameworks, data, and stakeholder input to ensure every sprint delivers maximum impact.

Prioritization Challenges

Problem	Cause	Solution
Everything is priority 1	No framework	Force ranking
Newest items jump queue	Recency bias	Consistent criteria
Loudest stakeholder wins	No process	Data + framework
Low-value work done first	No visibility	Value scoring
Priorities change constantly	No discipline	Sprint commitment

Prioritization Frameworks

RICE Framework

RICE SCORING METHOD
═══════════════════

FORMULA:
RICE Score = (Reach × Impact × Confidence) / Effort

COMPONENTS:
─────────────────────────────────────
REACH: How many users affected per quarter?
├── 1,000 = 1,000 users
├── 10,000 = 10K users
└── Use real numbers

IMPACT: How much does it help each user?
├── 3 = Massive (huge improvement)
├── 2 = High (major improvement)
├── 1 = Medium (noticeable improvement)
├── 0.5 = Low (minor improvement)
└── 0.25 = Minimal (barely noticeable)

CONFIDENCE: How sure are you?
├── 100% = High confidence
├── 80% = Medium confidence
├── 50% = Low confidence
└── Use honest assessment

EFFORT: Person-months of work
├── 1 = 1 person-month
├── 0.5 = 2 weeks
└── Whole numbers preferred

EXAMPLE:
─────────────────────────────────────
Feature: Improved search

Reach: 50,000 users/quarter
Impact: 2 (high)
Confidence: 80%
Effort: 2 person-months

RICE = (50,000 × 2 × 0.8) / 2 = 40,000

Compare to other features' RICE scores
Higher = higher priority

MoSCoW Method

MOSCOW CATEGORIZATION
═════════════════════

CATEGORIES:
─────────────────────────────────────
MUST HAVE:
├── Essential for release
├── Product fails without it
├── Non-negotiable
└── ~60% of effort

SHOULD HAVE:
├── Important but not vital
├── Painful to omit
├── Workaround possible
└── ~20% of effort

COULD HAVE:
├── Nice to have
├── Easy wins included
├── First to cut if needed
└── ~20% of effort

WON'T HAVE (this time):
├── Acknowledged desires
├── Explicitly out of scope
├── Future consideration
└── Documented, not forgotten

EXAMPLE SPRINT:
─────────────────────────────────────
MUST:
├── User login
├── Password reset
└── Profile creation

SHOULD:
├── OAuth integration
├── Remember me option

COULD:
├── Avatar upload
├── Two-factor auth

WON'T:
├── Social login
├── Biometric auth

IF RUNNING BEHIND:
├── Keep all MUST
├── Evaluate SHOULD items
├── Drop COULD items first
└── Never drop MUST

Value vs Effort Matrix

VALUE VS EFFORT MATRIX
══════════════════════

                  LOW EFFORT        HIGH EFFORT
             ┌──────────────────┬──────────────────┐
             │                  │                  │
   HIGH      │   QUICK WINS     │   BIG BETS       │
   VALUE     │   Do first!      │   Plan carefully │
             │   ★★★★★          │   ★★★★☆          │
             │                  │                  │
             ├──────────────────┼──────────────────┤
             │                  │                  │
   LOW       │   FILL-INS       │   AVOID          │
   VALUE     │   Do if time     │   Don't do       │
             │   ★★☆☆☆          │   ★☆☆☆☆          │
             │                  │                  │
             └──────────────────┴──────────────────┘

PRIORITY ORDER:
─────────────────────────────────────
1. QUICK WINS: High value, low effort
   Start here. Maximum ROI.

2. BIG BETS: High value, high effort
   Worth it, but plan well.

3. FILL-INS: Low value, low effort
   Use to fill gaps. Don't prioritize.

4. AVOID: Low value, high effort
   Why would you? Don't.

VISUAL PLACEMENT:
─────────────────────────────────────
Map each backlog item on the matrix.
Clear visualization helps discussions.
"Why are we doing that low-value item
when these quick wins are waiting?"

Process

Regular Prioritization

PRIORITIZATION PROCESS
══════════════════════

WEEKLY BACKLOG REFINEMENT:
─────────────────────────────────────
1. REVIEW NEW ITEMS (15 min)
   ├── Any new requests this week?
   ├── Initial value assessment
   ├── Rough effort estimate
   └── Add to backlog in right position

2. SCORE TOP ITEMS (20 min)
   ├── Apply RICE to top 20 items
   ├── Update if new information
   ├── Discuss any scoring disagreements
   └── Rank by score

3. VALIDATE WITH STAKEHOLDERS (15 min)
   ├── Does ranking match expectations?
   ├── Any strategic changes?
   ├── Missing context?
   └── Final adjustments

4. GROOM FOR SPRINT (10 min)
   ├── Are top items sprint-ready?
   ├── Clear acceptance criteria?
   ├── Sized appropriately?
   └── Dependencies identified?

OUTPUT:
─────────────────────────────────────
├── Prioritized backlog
├── Top items ready for sprint
├── Stakeholder alignment
└── Documented decisions

Handling Conflicts

RESOLVING PRIORITY CONFLICTS
════════════════════════════

COMMON CONFLICTS:
─────────────────────────────────────
├── Stakeholder A wants Feature X
├── Stakeholder B wants Feature Y
├── Both claim "highest priority"
└── Limited capacity

RESOLUTION FRAMEWORK:
─────────────────────────────────────
Step 1: Use data
├── What do RICE scores say?
├── Which has higher value?
├── Which has better ROI?
└── Data often resolves conflict

Step 2: Connect to strategy
├── What's the company priority?
├── Which aligns with goals?
├── CEO tiebreaker?
└── Strategy provides direction

Step 3: Facilitate discussion
├── Bring stakeholders together
├── Share data transparently
├── Let them hear each other
└── Often find compromise

Step 4: Product Owner decides
├── When consensus impossible
├── PO has final authority
├── Decision is documented
├── Move forward
└── Revisit if context changes

DOCUMENTATION:
─────────────────────────────────────
"Decision: Feature X prioritized over Y because:
- Higher RICE score (45K vs 32K)
- Aligns with Q1 revenue goals
- Lower risk, higher confidence
Feature Y planned for next quarter."

GitScrum Setup

Priority Management

GITSCRUM PRIORITIZATION
═══════════════════════

PRIORITY FIELD:
─────────────────────────────────────
Each item has priority:
├── P0 - Critical (blocks other work)
├── P1 - High (core functionality)
├── P2 - Medium (important)
├── P3 - Low (nice to have)
└── Used for quick filtering

CUSTOM FIELDS FOR RICE:
─────────────────────────────────────
Add fields:
├── Reach (number)
├── Impact (select: 0.25, 0.5, 1, 2, 3)
├── Confidence (select: 50%, 80%, 100%)
├── Effort (number)
├── RICE Score (calculated)
└── Sort by RICE descending

BACKLOG VIEW:
─────────────────────────────────────
View: Prioritized Backlog
Sort by: RICE Score (desc)
Group by: Priority level
Show: Title, RICE, Assignee, Status

LABELS:
─────────────────────────────────────
├── must-have (red)
├── should-have (yellow)
├── could-have (green)
├── wont-have (gray)
└── Quick MoSCoW filtering

Best Practices

For Prioritization

Use a framework — Consistent criteria

Score everything — Make value visible

Regular cadence — Weekly refinement

Single owner — Product Owner decides

Document decisions — Prevent re-litigation

Anti-Patterns

PRIORITIZATION MISTAKES:
✗ Everything is P1
✗ Newest = highest priority
✗ Loudest stakeholder wins
✗ No framework, gut feeling only
✗ Never saying "no" or "later"
✗ Reprioritizing mid-sprint
✗ Ignoring data for politics
✗ Not communicating priorities