Task Prioritization Methods | MoSCoW, RICE, Matrix
Prioritize work with MoSCoW, Value vs Effort matrix, RICE scoring, or stack ranking. GitScrum supports priority fields, drag ordering, and custom scoring.
7 min read
Not all tasks are equal. Good prioritization ensures teams work on the most valuable things first, avoid wasting time on low-impact work, and make trade-offs consciously. This guide covers practical prioritization methods for development teams.
Prioritization Methods
| Method | Best For | Complexity |
|---|---|---|
| Stack Ranking | Simple backlogs | Low |
| MoSCoW | Release planning | Low |
| Value vs Effort | Trade-off decisions | Medium |
| RICE | Objective scoring | High |
| WSJF | Scaled agile | High |
MoSCoW Method
Categorizing Priority
MOSCOW PRIORITIZATION
═════════════════════
CATEGORIES:
─────────────────────────────────────
MUST HAVE
├── Critical for success
├── System won't work without it
├── Regulatory/legal requirement
├── Core value proposition
└── Non-negotiable for release
SHOULD HAVE
├── Important but not critical
├── Significant value
├── Could work around if needed
├── High priority after Musts
└── Target for release
COULD HAVE
├── Nice to have
├── Adds value but not essential
├── Only if time allows
├── First to cut if behind
└── Included if capacity exists
WON'T HAVE (THIS TIME)
├── Explicitly out of scope
├── Prevents scope creep
├── Acknowledged as desired
├── Deferred to future
└── Not in this release
USAGE:
─────────────────────────────────────
Release planning:
├── All Musts = minimum viable release
├── Musts + most Shoulds = target
├── Add Coulds if ahead
├── Won't = clear expectations
└── Stakeholders see trade-offs
EXAMPLE:
─────────────────────────────────────
User Authentication Release:
MUST:
├── Email/password login
├── Password reset
├── Session management
SHOULD:
├── Google OAuth
├── Remember me
├── Account lockout
COULD:
├── GitHub OAuth
├── Two-factor authentication
├── Login history
WON'T (v1):
├── SAML/SSO
├── Biometric login
├── Passwordless login
Value vs Effort
Matrix Prioritization
VALUE VS EFFORT MATRIX
══════════════════════
│ LOW EFFORT │ HIGH EFFORT
────────┼─────────────────┼──────────────────
HIGH │ QUICK WINS │ MAJOR PROJECTS
VALUE │ Do First! │ Plan Carefully
│ (Best ROI) │ (Significant work)
────────┼─────────────────┼──────────────────
LOW │ FILL-INS │ AVOID
VALUE │ Maybe Later │ Don't Do
│ (If time) │ (Waste of effort)
PRIORITIZATION ORDER:
─────────────────────────────────────
1. Quick Wins: High value, low effort
Do these first—best ROI
2. Major Projects: High value, high effort
Worth doing, need planning
3. Fill-ins: Low value, low effort
Only if capacity exists
4. Avoid: Low value, high effort
Say no—opportunity cost too high
PLOTTING ITEMS:
─────────────────────────────────────
For each backlog item:
├── Rate Value: 1-10 (customer impact, revenue, urgency)
├── Rate Effort: 1-10 (time, complexity, risk)
├── Plot on matrix
├── Prioritize quadrant by quadrant
└── Visual makes trade-offs clear
TEAM EXERCISE:
─────────────────────────────────────
1. List all backlog items
2. Team rates effort (they know)
3. PO rates value (they know)
4. Plot on whiteboard/Miro
5. Discuss and adjust
6. Priority emerges visually
RICE Scoring
Objective Prioritization
RICE FRAMEWORK
══════════════
COMPONENTS:
─────────────────────────────────────
R = REACH
├── How many users affected per time period?
├── Number of customers/transactions/etc.
├── Quantify: "1000 users/month"
I = IMPACT
├── How much will it impact each user?
├── Scale: 3 = massive, 2 = high, 1 = medium,
│ 0.5 = low, 0.25 = minimal
├── Qualitative but standardized
C = CONFIDENCE
├── How sure are we of estimates?
├── 100% = high confidence
├── 80% = medium
├── 50% = low
├── Reduces score for uncertainty
E = EFFORT
├── Person-months of work
├── Include all roles (dev, design, QA)
├── Higher effort = lower priority
FORMULA:
─────────────────────────────────────
RICE Score = (Reach × Impact × Confidence) / Effort
Higher score = Higher priority
EXAMPLE:
─────────────────────────────────────
Feature A: New checkout flow
├── Reach: 10,000 users/month
├── Impact: 2 (high—conversion)
├── Confidence: 80%
├── Effort: 3 person-months
└── RICE = (10000 × 2 × 0.8) / 3 = 5,333
Feature B: Dark mode
├── Reach: 15,000 users/month
├── Impact: 0.5 (low—nice to have)
├── Confidence: 100%
├── Effort: 1 person-month
└── RICE = (15000 × 0.5 × 1.0) / 1 = 7,500
Prioritize: B then A (higher RICE)
WHEN TO USE RICE:
─────────────────────────────────────
├── Comparing many features
├── Need objective criteria
├── Stakeholder disagreements
├── Data-driven decisions
└── Removes politics from prioritization
Stack Ranking
Simple Ordering
STACK RANKING
═════════════
CONCEPT:
─────────────────────────────────────
One ordered list.
No ties allowed.
Most important at top.
HOW TO BUILD:
─────────────────────────────────────
1. Start with two items
"Which is more important?"
Put winner on top.
2. Take next item
"Where does this fit?"
Insert in order.
3. Repeat for all items
Binary comparisons throughout.
Final list is fully ordered.
BENEFITS:
─────────────────────────────────────
├── Simple—no frameworks needed
├── Clear—no ambiguity
├── Forces decisions—no "both P1"
├── Easy to follow—start at top
└── No gaming—can't all be high priority
EXAMPLE:
─────────────────────────────────────
Sprint Backlog (Stack Ranked):
1. Fix payment bug (blocking sales)
2. User login flow (release blocker)
3. Dashboard improvements (customer request)
4. Search feature (roadmap item)
5. Performance optimization (tech debt)
6. Dark mode (nice to have)
Rule: Work on #1 first.
Only move to #2 when #1 is done.
Stack is the priority.
WHEN TO USE:
─────────────────────────────────────
├── Small backlogs (<30 items)
├── Simple prioritization needed
├── Single decision-maker
├── Sprint-level planning
└── When frameworks are overkill
Prioritization Process
Involving the Right People
PRIORITIZATION ROLES
════════════════════
WHO DECIDES WHAT:
─────────────────────────────────────
PRODUCT OWNER:
├── Final priority decision
├── Value assessment
├── Stakeholder balance
├── Trade-off calls
└── Owns the backlog order
STAKEHOLDERS:
├── Business value input
├── Urgency context
├── Customer insights
├── Strategic alignment
└── Influence, don't dictate
TEAM:
├── Effort estimates
├── Technical feasibility
├── Dependency identification
├── Risk assessment
└── Reality check on priorities
USERS:
├── Needs validation
├── Pain point severity
├── Feature feedback
├── Usage data
└── Ground truth
PROCESS:
─────────────────────────────────────
1. Gather input from all sources
2. PO synthesizes into priority
3. Team reviews for feasibility
4. Stakeholders acknowledge trade-offs
5. PO finalizes
6. Team executes in priority order
GitScrum Prioritization
Priority Features
GITSCRUM PRIORITIZATION
═══════════════════════
PRIORITY FIELD:
─────────────────────────────────────
Task → Priority
├── Critical
├── High
├── Medium
├── Low
└── Custom levels available
ORDERING:
─────────────────────────────────────
Backlog → Drag to reorder
├── Stack rank visually
├── Top = highest priority
├── Drag and drop
└── Saved automatically
PRIORITY VIEWS:
─────────────────────────────────────
Filter by:
├── Priority level
├── Custom fields
├── Labels (MoSCoW tags)
└── Focus on high priority
SCORING:
─────────────────────────────────────
Custom fields for:
├── Value score
├── Effort score
├── RICE components
├── Calculated priority
└── Data-driven ordering
BACKLOG REFINEMENT:
─────────────────────────────────────
Refinement session:
├── Review priority order
├── Discuss trade-offs
├── Adjust based on new info
├── Keep backlog healthy
└── Regular maintenance
Best Practices
For Prioritization
Anti-Patterns
PRIORITIZATION MISTAKES:
✗ Everything is "P1"
✗ Decision by committee
✗ Never reprioritizing
✗ No clear owner
✗ Ignoring team input on effort
✗ Politics over value
✗ No trade-off acknowledgment
✗ Changing priority constantly