MoSCoW prioritization: a practical requirements example

Not every important requirement is essential right now

MoSCoW separates requirements by how necessary they are for a chosen period.

The team has two weeks before registration opens for a workshop. The client wants a form, filters, promo codes, polished animations and a customer account. If everything is called essential, the list will not help the team make a decision when the first delay arrives.

The method offers four categories: Must Have means the agreed outcome is unacceptable without it; Should Have means it is important but an acceptable temporary workaround exists; Could Have is a useful addition; Won’t Have this time is deliberately excluded from this period. The last category does not mean “never”.

The following is an illustrative example of prioritizing a small launch. Its figures and decisions are not a standard. In another project, the same feature could belong in a different group: necessity depends on the goal and constraints, not the feature’s name.

Define the decision’s scope first

Record the date, audience and minimum acceptable outcome. In our example, visitors must be able to see the terms, choose an available place and receive confirmation. The team is not promising a complete learning platform. This boundary lets people discuss requirements without continually expanding what “launch” means.

Identify constraints that cannot simply be traded for convenience: mandatory security requirements, data handling requirements and agreements with participants. This article does not replace checking them. Labeling something Could does not make a mandatory requirement optional.

Ask about the specific release rather than an ideal product. Automated booking changes may be necessary in a mature service, but for one session with ten participants, the team might temporarily handle changes manually.

A completed example for a workshop

Here, the email is a Should only if a reliable alternative confirmation exists. If the page disappears and people have nowhere else to find the details, that decision has no valid basis. A classification must describe a real workaround, not an imagined ability to “manage somehow”.

For each disputed requirement, record a short reason and who agreed to the decision. A week later, recovering the reasoning will matter more than remembering why a card has a particular color.

What to do when everything is a Must

Ask participants to remove one requirement at a time and describe the consequences. “The client will not like it” signals a need to clarify expectations, but does not yet prove that a release is impossible. “We cannot allocate places correctly” identifies a specific constraint on the chosen outcome.

Then check the scope: the team may be trying to launch several different products in one period. You can narrow the audience, number of scenarios or size of the offering. For example, keep one workshop instead of a catalog of ten. This changes the basis of the decision and needs agreement, but is often more honest than promising everything.

Do not assign the essential group an arbitrary percentage just to make a chart look balanced. If the essential minimum still exceeds available capacity, change the deadline, scope or delivery approach. Renaming a Must as a Should does not remove the constraint.

Handling a delay halfway through the work

By Wednesday, it becomes clear that booking changes will take longer than expected. Within the agreed scope, this is a Should rather than a Must. The team keeps manual changes through the organizer, publishes clear contact details and retains automation for the next discussion. Essential registration and confirmation continue to be checked.

If protection against booking an occupied place were delayed, the decision would be different. A polished animation cannot make up for it. The team would need to change the booking process, reduce the launch scope or postpone the release. MoSCoW is useful because it distinguishes the consequences, not because it puts four labels in a table.

A workaround also has a cost: the organizer must be available, know the rules for booking changes and be able to handle the request. Check this operational side before accepting the trade-off. Otherwise, reducing technical scope simply transfers the problem to the participant.

Keeping categories from becoming permanent labels

After release, review the reasoning. If there are now ten sessions, a filter may become more important. If manual booking changes become too frequent, automation has a different justification. A category can reasonably change when the facts or the period’s goal change.

Do not change a category quietly to win an argument in a work chat. Record the new circumstance: what outcome is now impossible without the requirement, what evidence supports this and what must be postponed instead. This preserves trust in prioritization.

1. Name the period and goal for the decision.
2. For every Must, check the consequences of leaving it out.
3. For a Should, describe a real temporary workaround.
4. For a Could, make sure the addition does not displace the essential minimum.
5. For a Won’t, keep the reason for exclusion and the condition for revisiting it.

Where to keep the working result

In Sinqly, you can create a task called “Agree on the minimum for the first launch” and add the four requirement groups, decision reasons and review date to its description; registration is free.

DesktopMobile

View screenshot ↗

Close ×

An actual Sinqly task card from the screenshot library: the description field shows a different training example in Russian. The content from this article is transferred manually; the screenshot does not show a dedicated MoSCoW module.

What to use alongside MoSCoW

A single category can still contain several tasks. The method alone does not choose their sequence, estimate effort or resolve dependencies. Secure the essential outcome first, then separately decide which Should offers the most value within the available constraints.

If the disagreement is about comparing dozens of initiatives rather than necessity, another evaluation method may help. MoSCoW does not need to answer every question about managing work. Its strength is a transparent discussion of what can be sacrificed in a particular period.

Other task prioritization methods — when you need additional grounds for choosing.