MoSCoW prioritisation when everything fits in scope
Stefan-Iulian Tesoi · · 6 min read
Only if the won't-have list is enforced. MoSCoW relied on the timebox running out, so could-haves dropped off on their own. With a coding agent the time rarely runs out, could-haves ship by default, and each one adds review, support and maintenance. The category doing the work now is won't have, written down with its reason.
MoSCoW prioritisation was built as a scope tool for a fixed timebox. Agents removed the scarcity of building time it was designed around, and left in place every cost that comes after the build.
What was MoSCoW prioritisation relying on?
A fixed timebox that could not hold everything. Dai Clegg devised the MoSCoW method at Oracle in 1994, and DSDM made it the centre of its timeboxing. The four categories are must have, should have, could have and won't have this time. Many teams use it as a must-have should-have could-have ranking and quietly drop the fourth category, which is the one that matters once agents build.
The Agile Business Consortium's guidance on MoSCoW reads Must as the Minimum Usable SubseT and recommends typically no more than 60% Must Have effort and around 20% Could Have effort. The could-haves "provide the main pool of contingency": when the deadline is at risk, they are the first choice of what to drop.
| Category | What it means in DSDM | When time ran short | When agents build |
|---|---|---|---|
| Must have | The minimum usable subset | Delivered | Delivered |
| Should have | Important, but has a workaround | Delivered if possible | Delivered |
| Could have | Desirable, and the contingency pool | Dropped first | Delivered by default |
| Won't have this time | Agreed out of this timeframe | Recorded, not built | The only limit left |
The method depended on the calendar doing the cutting. Nobody had to argue against a could-have, because the timebox ended before anyone reached it.
Why could-haves now ship by default
Because the contingency they provided is never called on. When a coding agent has finished the musts and shoulds by day three of a two-week timebox, no deadline is at risk, and the could-haves get built because building them is easy.
Each one still takes 10 to 20 minutes to review against its criteria, adds a screen or a path someone has to support, needs a line in the documentation, and brings a test that can go flaky. Ten could-haves in a sprint is two to three hours of review alone, spent on work nobody decided was worth owning. That is scope creep without anyone asking for more, and sprint planning with agents has to catch it at readiness, because the timebox no longer will.
The opposite failure exists too. Laimonade once counted a nice-to-have as required work, and a single unbuilt item held a finished milestone at 90 percent indefinitely. The fix was to keep two questions apart. Priority on an item says when; a separate optional flag says whether, and an optional item counts toward no milestone's progress until someone decides to build it. A could-have deserves that status explicitly, not by sitting at the bottom of a list.
What belongs on the won't-have list?
Every request that was considered and declined for this timeframe, each with a reason, an owner and a condition for coming back. DSDM's guidance says won't-haves are recorded in the Prioritised Requirements List, which "avoids them being informally reintroduced at a later date." With agents, informal reintroduction is the default route: someone asks for it in a chat, and twenty minutes later there is a pull request.
A useful won't have list records five things per entry:
- The request, in the words of whoever asked for it.
- Why not now: the outcome it does not serve, or the upkeep it would add.
- Who declined it, by name.
- What would change the answer: a customer count, a contract, a metric.
- When it will be looked at again, as a date.
An entry without the fourth field is a refusal with no way back, and it gets ignored. An entry without the third is a list nobody owns, and anything on it can be built by whoever finds it first.
When the calendar no longer says no, the won't-have list has to say it in writing.
Does the 60 percent rule still mean anything?
As a limit on build effort, barely; as a limit on review capacity, yes. The rule existed to guarantee contingency. When an agent compresses build effort, 60% of build time on must-haves fits with room to spare, and the rule stops constraining anything.
Measured in review hours, it works again. Review is where a team's capacity runs out now, so musts should take no more than 60% of the hours the team can spend reviewing, leaving the rest for rework and for the shoulds. A team with eight review hours a week plans about five of them for musts. The same reasoning sets sprint length for teams running agents: the boundary follows the slower of the two numbers, and building is no longer the slower one.
A MoSCoW session for an agent-built release
The session keeps its shape. Items are priced in review and upkeep rather than build time, and it ends when the won't-haves are written down.
- List the candidates. Fourteen items for the release.
- Mark the minimum usable subset. Four musts, the release fails without them.
- Price the rest in review hours and upkeep, not in how long the agent takes.
- Keep three shoulds, and one could that serves the release's stated outcome.
- Move the other could-haves to won't have this time, each with a reason, an owner and a date.
- Agree what an idle agent does: maintenance and test coverage, not optional scope.
Eight items get built and six are declined on paper. The same habit at a larger scale is the product roadmap when building gets cheap, which also has to say what not to build.
Frequently asked questions
Is a won't-have permanent?
No. DSDM's wording is won't have this time, and the qualifier matters. A won't-have is declined for one timeframe, with the condition that would reopen it, and unmet requirements are reprioritised at the end of each increment. What keeps the list working is that coming back requires the reason to have changed, not the request to have been repeated.
Who can move an item out of won't have?
The person who owns the product's priorities, usually the product owner or product manager, and only by recording why. A stakeholder can ask, an engineer can argue and an agent can draft the case, but moving it is a decision with a name on it. A won't-have that anyone can quietly start building is a suggestion, not a list.
Should could-haves be built when an agent is idle?
Usually not. An idle agent is a reason to pull maintenance, test coverage or the next must-have forward, not to build optional scope because it is quick to write. A could-have still costs review time and upkeep after the build. Build it when it serves the current outcome and someone has decided it is worth owning.