7.2 Value Prioritization Techniques
Key Takeaways
- MoSCoW prioritization categorizes backlog items into Must Have, Should Have, Could Have, and Won't Have this time, ensuring a viable minimum core capability.
- The Kano Model classifies customer requirements into Basic/Must-Be, Performance, Delighters/Attractive, Indifferent, and Reverse, illustrating how customer expectations decay over time.
- Weighted Shortest Job First (WSJF) calculates priority by dividing Cost of Delay (CoD) by Job Size, maximizing economic value delivery in enterprise agile frameworks like SAFe.
- Karl Wiegers' Relative Weighting method calculates a priority score by balancing relative feature benefits and penalties against relative development costs and technical risks.
- Collaborative techniques like the 100-Point Method (Monopoly Money) and Pairwise Comparison force stakeholders to quantify trade-offs and resolve conflicting business priorities.
7.2 Value Prioritization Techniques
In traditional project management, scope is often treated as fixed, while time and cost are variable. In agile project management, time and cost are fixed (via timeboxed iterations and stable cross-functional teams), while scope is variable. Therefore, the order in which backlog items are developed dictates project success.
Value Prioritization is the process of ranking Product Backlog items to maximize return on investment (ROI), minimize risk, and deliver early business value. The Product Owner holds ultimate accountability for prioritization, but relies on quantitative models and stakeholder collaboration tools to make objective decisions.
1. MoSCoW Prioritization
Originally developed as part of the Dynamic Systems Development Method (DSDM), MoSCoW Prioritization categorizes requirements into four distinct levels of priority:
| Category | Definition | Capacity Allocation Rule |
|---|---|---|
| Must Have (M) | Non-negotiable core capabilities required for launch. Without these, the release fails or is illegal/unsafe. | Target ~60% of total iteration effort. |
| Should Have (S) | Important features that add significant value, but for which viable manual workarounds exist if omitted. | Target ~20% of total iteration effort. |
| Could Have (C) | Desirable "nice-to-have" enhancements included only if extra capacity remains after Musts and Shoulds. | Target ~20% of total iteration effort. |
| Won't Have (W) | Features explicitly agreed to be out-of-scope for the current timebox/release, but reserved for future consideration. | 0% capacity in current release. |
PMI-ACP EXAM TIP: MoSCoW acts as a risk buffer. By capping "Must Haves" at 60% of capacity, the team builds in a 40% contingency (Shoulds + Coulds) to absorb unexpected complexity without missing the hard release deadline.
2. Noriaki Kano Model
Created by Professor Noriaki Kano, the Kano Model maps customer preference against feature execution to understand what truly drives user satisfaction.
The model classifies requirements into five distinct categories:
- Basic / Must-Be Quality: Mandatory baseline expectations (e.g., a hotel room having clean hot water or a banking app allowing logins). Their presence does not increase satisfaction, but their absence causes severe customer dissatisfaction.
- Performance / One-Dimensional Quality: Features with linear satisfaction response (e.g., smartphone battery life or processing speed). More is directly better.
- Delighters / Attractive Quality: Unexpected, novel features (e.g., free high-end noise-canceling headphones with a hotel booking). Absence causes zero dissatisfaction (users didn't expect it), but presence creates high satisfaction and delight.
- Indifferent: Features that users simply do not care about regardless of implementation quality.
- Reverse: Features that actively annoy users when present (e.g., intrusive auto-playing video popups).
Feature Decay Dynamics
Over time, features migrate downward through Kano categories. Yesterday's Delighter (e.g., Wi-Fi on an airplane) becomes today's Performance expectation and tomorrow's Basic Must-Be requirement.
3. Weighted Shortest Job First (WSJF)
Popularized by Don Reinertsen and integrated into the Scaled Agile Framework (SAFe®), WSJF is a quantitative prioritization algorithm designed to sequence jobs to achieve the maximum economic benefit.
Calculating Cost of Delay (CoD)
Cost of Delay is calculated by adding three relative business components (typically scored on a Fibonacci scale: 1, 2, 3, 5, 8, 13, 20):
WSJF Calculation Example
| Feature | User/Biz Value | Time Criticality | RR / OE | Cost of Delay (CoD) | Job Size | WSJF Score | Priority |
|---|---|---|---|---|---|---|---|
| Feature A | 8 | 5 | 3 | 16 | 2 | 8.0 | 1st |
| Feature B | 13 | 8 | 5 | 26 | 13 | 2.0 | 3rd |
| Feature C | 5 | 2 | 1 | 8 | 3 | 2.67 | 2nd |
Key Insight: Feature A delivers a higher WSJF score than Feature B because Feature B's massive job size (13) dilutes its return rate, whereas Feature A delivers rapid value quickly.
4. Karl Wiegers' Relative Weighting Method
Software engineering expert Karl Wiegers introduced a relative prioritization matrix that balances business value against development effort and technical risk.
Operational Steps:
- List proposed features.
- Estimate Relative Benefit (value to customer if present) and Relative Penalty (negative impact if absent) on a scale of 1 to 9.
- Calculate Total Value = Benefit + Penalty.
- Estimate Relative Cost (1-9 scale) and Relative Technical Risk (1-9 scale).
- Convert Values, Costs, and Risks into percentage contributions of the column totals.
- Divide Value % by the combined weighted Cost % and Risk % to calculate the final priority index.
5. Collaborative Group Prioritization Methods
When managing divergent opinions across business executives, Product Owners leverage consensus-building prioritization games:
100-Point Method (Monopoly Money)
Each stakeholder is given a fixed budget of 100 points (or $100 in fake "Monopoly money") to distribute across a list of candidate user stories.
- Stakeholders can allocate all 100 points to a single critical feature or spread them across multiple stories.
- Summing points across all stakeholders exposes true organizational priorities and prevents the common trap where stakeholders mark every request as "High Priority".
Pairwise Comparison (Analytic Hierarchy Process)
When ranking items is highly contentious, the team conducts a systematic pairwise tournament. Every backlog item is compared directly against every other item in a one-on-one comparison:
For 5 items (A, B, C, D, E), 10 head-to-head comparisons are made. The item winning the highest number of pairwise choices ranks #1 on the backlog.
An agile team is using MoSCoW prioritization for a 3-month release timebox. During iteration planning, stakeholder requests threaten to fill 90% of the iteration capacity with 'Must Have' features. How should the Product Owner respond based on agile best practices?
Using the Scaled Agile Framework (SAFe) Weighted Shortest Job First (WSJF) formula, a Product Owner needs to prioritize two features. Feature X has a Cost of Delay of 15 and a Job Size of 3. Feature Y has a Cost of Delay of 24 and a Job Size of 8. Which feature should be prioritized first and why?
A mobile app product team conducts a Kano Model survey. Users indicate that if biometric fingerprint login is absent, they are completely unbothered, but when present, user delight and app review ratings increase drastically. How is fingerprint login categorized in the Kano Model?