Prioritised Requirements That Are Not Really Prioritised
A local authority project is replacing a case-management system. The requirements list has 210 items. When reviewed, 168 are marked Must. The Business Visionary explains that 'everything a caseworker does is legally required'. The Solution Development Team has just finished the first timebox and delivered 9 of 14 planned items; the shortfall was caused by two requirements that turned out to need integration work nobody had estimated. The Project Manager is about to start timebox 2 planning and the requirements list is still unchanged. The Technical Coordinator warns that the next timebox contains three more items of the same integration type.
1. Diagnose the MoSCoW problem and explain its effect on the project's ability to deliver on time.
Read the worked answer
MoSCoW only works if Must is a small, genuinely non-negotiable core - typically no more than around 60% of effort - so that Should and Could provide the contingency that absorbs estimation error. With 168 of 210 items as Must (80%), there is no contingency at all: every estimate error becomes a schedule overrun.
The first timebox demonstrates exactly this: 9 of 14 delivered, and the shortfall was estimation error on integration work, which is normal and expected. With no Should/Could buffer, that error cannot be absorbed - it must be paid for by dropping Must, which the business will not accept.
The 'legally required' claim needs testing. Legal obligation usually attaches to an outcome (the case record is retained and auditable), not to every UI feature. Many of the 168 are likely Should ('we need it at go-live but there is a manual workaround') or Could. Without that distinction the project has no flex and will fail its date.
2. What would you do before timebox 2 planning, and how do you handle the three known integration items?
Read the worked answer
Before planning: run a facilitated prioritisation workshop with the Business Visionary and Business Ambassador, forcing each of the 168 Musts to justify itself against two questions - 'what legally fails if this is absent at go-live?' and 'is there an acceptable manual workaround for the first release?'. Anything with a workaround becomes Should. Target a Must set that fits measured capacity with headroom. Document the rationale so the prioritisation is defensible to auditors.
For the three integration items: they are known high-risk, high-uncertainty work. Options: (a) move them earlier so failure is discovered while there is still time to react, (b) split each into a thin end-to-end slice plus later elaboration, and (c) ensure the timebox plan carries explicit contingency rather than assuming the previous underestimate will not recur. Also feed the integration estimate back into the re-forecast so the sponsor sees the revised date/scope position now, not at the end.