Prioritised Requirements List That Nobody Can Prioritise
A project is 4 timeboxes into an 8-timebox delivery. The Prioritised Requirements List contains 140 items. On inspection, 96 are marked 'Must have', 30 'Should have', 10 'Could have' and 4 'Won't have this time'. The business analyst explains that stakeholders 'couldn't agree' so most items were marked Must to be safe. The last two timeboxes overran by 4 and 6 days respectively. The project manager wants to add contingency by extending the remaining timeboxes by 20%. The business sponsor is concerned but has not seen the PRL. The team leader reports that the team is demoralised because 'everything is a must'.
1. Diagnose the problem with this PRL against AgilePM guidance and explain the consequences.
Read the worked answer
The PRL is effectively unprioritised. AgilePM expects MoSCoW to be applied so that a workable proportion of effort is 'must have' - commonly guided at roughly 60% must, 20% should, 20% could (the exact split is a guide, not a rule). Here 96/140 ≈ 69% are Must, and the 'Won't' category is being misused as a parking lot rather than a genuine current-scope exclusion.
Consequences:
- No scope to flex: timeboxing fixes time and cost and flexes scope. If nearly everything is a Must, nothing can be dropped when a timebox runs late - which is exactly why the last two overran.
- Loss of predictability: the overruns are a symptom, not a cause. The cause is that the team cannot trade scope against time.
- Demoralisation: 'everything is a must' removes the team's ability to deliver a coherent increment and meet the timebox; AgilePM's 'Collaborate' and team empowerment principles are undermined.
- Business case risk: the sponsor cannot see what is genuinely essential, so cannot judge whether the business case still holds.
- False safety: marking items Must 'to be safe' achieves the opposite - it guarantees lateness.
Root cause: stakeholders were allowed to avoid prioritisation. MoSCoW is a business decision requiring business role involvement, facilitated by the business analyst/project manager, not a technical labelling exercise.
2. The PM proposes extending remaining timeboxes by 20%. Evaluate this against the alternative of re-prioritising the PRL.
Read the worked answer
Extending timeboxes by 20% treats the symptom and breaks a core control.
Against extension:
- It abandons the fixed-time principle. Timebox length should be stable so velocity is measurable and predictable; a one-off 20% extension resets the baseline and signals that deadlines are negotiable.
- It does not address the 69% Must problem - if everything is still a Must, the longer timeboxes will simply absorb more Must work and overrun again.
- It hides the issue from the sponsor rather than surfacing it.
For re-prioritisation:
- It restores the mechanism that makes timeboxes work: fix time, flex scope.
- It gives the sponsor a meaningful view of the business case (what is truly essential).
- It is cheap and immediate - no schedule change needed.
Recommended course:
- Convene the business sponsor, business ambassador(s) and business analyst to re-run MoSCoW on the 96 Musts, driving toward a workable must-proportion (e.g. ~60%). Genuine Musts are those without which the solution has no value or is illegal/unsafe.
- Move deferrable items to Should/Could and confirm a proper 'Won't have this time' set.
- Show the sponsor the PRL and the last two overruns so the trade-off is explicit.
- Only if, after re-prioritisation, the remaining Musts genuinely cannot fit, consider a scope or timescale change agreed with the sponsor - as a business decision, not a PM convenience.
- Keep timebox length stable; use the re-prioritised PRL to protect it.