Add each requirement with an effort estimate, sort it into Must, Should, Could or Won't have this time, and the four groups total themselves below the table. A flag appears if Must have passes the 60% of effort the DSDM Agile Business Consortium's own handbook sets as the ceiling.
| Requirement | Effort, days | Category | Remove |
|---|
The rows above are a worked example of a small release. Replace them with your own.
Nothing on this page is sent anywhere. The rows live in the browser tab and disappear on reload, which is also why the export button exists.
What each category means
The four categories are the DSDM Agile Business Consortium's own terms, read from its project framework handbook on 3 October 2026.
Must have. The minimum usable subset the release guarantees to deliver. Without it, shipping is pointless, not just disappointing.
Should have. Important but not vital. Painful to leave out, and the release still works without it, usually with a workaround.
Could have. Wanted or desirable, and the first thing to drop if the schedule is at risk. DSDM calls a Could Have pool of around 20% of effort a sensible level of contingency, so an empty Could bucket is as much a warning sign as an empty Won't bucket.
Won't have this time. Explicitly out of scope for this release, written down so nobody argues about it later. The "this time" is the whole point: it says when, not never.
A worked example
The rows loaded above are a small release for a feedback board product, eight requirements, sorted once.
Must have holds login, the mobile layout fix and custom domain support, 4 of the 8 effort days. Should have holds CSV export and weighted voting, 2 days. Could have holds dark mode and the roadmap embed, 2 days. Slack notifications is Won't have this time, out of the 8 in scope days entirely.
Must have's share of the 8 in scope days is 50%, under the 60% ceiling, so no flag shows.
Sort the same eight requirements by what feels important instead of by capacity, and CSV export and weighted voting slide into Must have too. Must have's effort jumps to 6 of 8 days, 75%, and the tool flags it. That is the method's own check working: nothing changed about the requirements, only about whether a capacity was respected.
How to run a MoSCoW session with a team
Write the effort capacity down before anyone sees the requirement list. A number agreed after the sorting starts will bend to fit whatever got called Must.
Sort in one sitting, out loud, so a disagreement surfaces as an argument about one requirement rather than as a silent vote.
Fill Must have against the capacity first, then Should have against what is left, then Could have. Whatever does not fit is Won't have this time, not a fifth, unlabeled bucket.
Check the Must have share against 60% before anyone leaves the room. If it is over, something moves down, not the ceiling up.
The two mistakes people make
Everything is a Must. Sorted by importance instead of by capacity, almost every requirement earns a reason to be essential, because somebody wanted it. DSDM's own warning is explicit: Must have above 60% of effort is a risk to the release, not a sign of commitment.
Won't reads as never. A requirement marked Won't have this time with no "this time" attached gets treated as refused forever, and the person who asked stops asking. Writing the date or the release name next to a Won't have keeps it a scheduling decision instead of a rejection.
MoSCoW next to RICE and a value and effort matrix
MoSCoW sorts a fixed list into four buckets against a capacity. RICE scores an open list by reach, impact, confidence and effort, producing a rank rather than a bucket. Use MoSCoW when a release date is fixed and the question is what fits; use RICE when the list is still open and the question is what to build first.
A prioritization matrix plots value against effort on two axes instead of sorting into four named buckets. It answers a quadrant question, high value or low, high effort or low, where MoSCoW answers a scope question, in this release or not.
The full method, with where it comes from and where teams get it wrong covers all three side by side. A twenty request MoSCoW example runs the method twice over a bigger list and finds the same 60% trap.
Where the requirements come from
Sorting into four buckets still needs a list of requirements, and effort for each. A feedback board such as VoteFirst is where that list usually starts: visitors vote on requests with no account, so a request's votes are already counted before anyone sorts it. VoteFirst has no Must, Should, Could or Won't field on a request; the four categories live in the spreadsheet or the tool above, not on the board.
14 days, a card at signup, then $9 or $39 a month.
Is there a downloadable template?
Yes. Take the xlsx. It carries the same eight requirements, with formulas that count each category, total its effort and write the same 60% flag the tool above shows, so the arithmetic survives in Excel, Numbers or LibreOffice without the page open.