Four MoSCoW worksheets you can copy straight off the page.

What Must have, Should have, Could have and Won't have mean

MoSCoW sorts every candidate item into four categories against one fixed deadline: Must have, Should have, Could have, and Won't have this time. The two lowercase o's are filler that make the acronym pronounceable and stand for nothing.

A Must have is not the same thing as important. The Agile Business Consortium, the standards body behind DSDM, defines the Must haves as "the Minimum Usable SubseT (MUST) of requirements which the project guarantees to deliver", spelled with a capital T because the backronym is M-U-S-T. Wikipedia, citing the IIBA's Business Analysis Body of Knowledge, states the same test from the other side: "If even one Must have requirement is not included, the project delivery should be considered a failure." That is the bar. If a workaround exists, or the release would still be worth shipping without it, the item is a Should have.

A Should have hurts to leave out and has a workaround, however ugly. A Could have is wanted, costs little to omit, and is the first thing dropped when the Must haves run long. DSDM treats the Could haves as the release's contingency pool, which is why it is the only category other than Must with a recommended size.

Won't have this time is the category teams skip and the one that does the most work. It is a dated decision, not a rejection. Wikipedia records that the variant "Would like to have" is incorrect usage, because this last priority states that something is outside the scope of delivery, and notes that the BCS, in later editions of its business analysis book, phrases the W as "Want to have but not this time around". The W is the contested letter. Writing the reason and the date beside each item is what stops it being re-argued in the next planning session.

How much of a release can be a Must have

DSDM puts a number on this, and it is the number almost no MoSCoW template carries. The Agile Business Consortium states that "the safe percentage of Must Have requirements, in order to be confident of project success, is not to exceed 60% Must Have effort", and recommends a pool of Could haves "that reflects a sensible level of contingency", typically around 20% Could have effort.

Three precisions separate that rule from the version most summaries carry. The 60% is a share of effort, not of item count: DSDM says so explicitly, "in terms of effort to deliver". It applies to a project or Project Increment, not to a single day's to-do list. And there is no prescribed Should have percentage: Should is the remainder, and the Agile Business Consortium is explicit that the exact split between Musts, Shoulds and Coulds is each team's to agree. So the defensible reading is Must haves at no more than 60% of effort, a Could have pool near 20%, and Should haves as whatever is left. The third number is arithmetic, not guidance.

The reasoning behind the figures is the part worth keeping. In the same source: "anything other than a Must Have is, to some degree, contingency, since the Must Haves define the Minimum Usable SubseT which is guaranteed to be delivered." A plan that is 90% Must have effort has 10% contingency, so the first thing that goes wrong is paid for by breaking a promise. A plan at 60% can absorb a bad estimate by dropping Coulds nobody was promised. That is the whole mechanism, and it is why MoSCoW is not just high, medium and low with different words.

Both figures come from the Agile Business Consortium's "What is MoSCoW Prioritisation?" resource, checked on 19 September 2026. Wikipedia's MoSCoW article carries the method's origin but no percentage guidance at all, so a page citing Wikipedia for the 60% figure is citing the wrong source.

Where MoSCoW prioritization comes from

MoSCoW was not invented by DSDM, and getting that order right is worth one sentence because several widely read pages have it backwards. Wikipedia states that "this prioritization method was developed by Dai Clegg in 1994 for use in rapid application development (RAD)" and that "it was first used extensively with the dynamic systems development method (DSDM) from 2002". Created in 1994 for RAD, adopted by DSDM eight years later.

That history explains the shape of the method. RAD and DSDM both fix the deadline and flex the scope, which is the inverse of a fixed-scope plan, and MoSCoW is the instrument that makes flexing safe: the Must haves are the part of the scope that does not flex, and everything else is graded by how much it can. Used on a project where the deadline is negotiable, MoSCoW loses most of its point, because nothing forces the four categories to be different sizes.

The method's documentation is split across two sites, which is why so many summaries carry half of it. Wikipedia has the origin, the etymology and the criticisms, and no percentages. The Agile Business Consortium has the effort guidance and the Minimum Usable SubseT definition, and no origin. This page carries both, and names which is which.

Which MoSCoW worksheet to use when

Four worksheets, one method. They differ in what the timebox is, how much rationale each item carries, and who has to sign the result. Pick by the meeting you are walking into, not by the size of the product.

All four are plain text. Select one, copy it, and paste it into a spreadsheet, a Word document, a Notion page, a Jira description or a Confluence page. That covers what people usually mean by a MoSCoW Excel template or a MoSCoW template in Word: the structure is the template, and the file format is whatever you already use. There is nothing to download, no account to create and no canvas to learn, which is what the other MoSCoW templates ask for first.

Every worksheet is filled in with a worked example rather than left as four empty headings, because the hard part of MoSCoW is not the four labels. It is the rationale line next to each item and the honesty of the Must have test, and neither is visible in an empty grid.

What MoSCoW does not do

MoSCoW has one well-documented weakness, and Wikipedia's list of criticisms leads with it: the method "does not help decide between multiple requirements within the same priority". The same list names three more, all recognisable to anyone who has run a session: no rationale for why something is a Must rather than a Should, ambiguity over whether a Won't have means not this release or not ever, and a drift toward visible new features over technical work such as refactoring.

Three of the four are fixed by writing more down rather than by changing method. A one-line reason beside each category kills the rationale problem. A revisit date on every Won't have resolves the ambiguity. Putting technical work through the same Must have test as features, in the same list, stops the quiet demotion of the work that keeps the system standing.

The first one is not fixable inside MoSCoW, and it is the honest limit of the method. Once a release has fourteen Should haves and room for six, MoSCoW has stopped being the right instrument, because all fourteen are in the same bucket by definition. A scoring model puts a number on each item and orders them. RICE multiplies reach by impact and confidence, divides by effort, and produces a ranked list, which is exactly the ordering MoSCoW refuses to give you. The two work in sequence rather than in competition: MoSCoW decides what the release has to contain, and a score decides the order of everything after that.

From a sorted list to a roadmap people can see

A finished MoSCoW worksheet has a short half-life. It is accurate on the day of the session, and within a fortnight the Should haves have been re-argued, the Won't haves have quietly come back, and the customer who asked for the biggest one has emailed to ask what happened to their request.

That is the loop Sleekplan closes. Feature requests arrive on one board from the widget, the portal and your support tools, carrying votes and the accounts behind them, so the Must have argument starts from counts and named customers instead of from whoever is most insistent in the room. The items you keep move onto a public roadmap in Planned, In progress and Shipped columns, and the Won't have this time decisions stay visible with a status and a reason, which is the difference between a deferral a customer can read and a request that appears to have vanished. When something ships, the changelog notifies every person who voted for it.

The worksheet on this page is still the right place to do the thinking. What the product replaces is the part after the session: keeping the four categories true as the release moves, and telling the people who asked.