Why does an ordinary priority list often fail?
Many projects number requirements from most to least important. The approach appears logical, but several problems quickly emerge.
First, the number does not explain what the level actually means. Can a priority 2 feature be removed? Must priority 3 be included in the first release? Does the difference between items 4 and 5 have any practical significance?
Second, stakeholders often compete for the highest rating. As a result, most items receive priority 1 and the system becomes useless for decision-making.
Third, a ranked list suggests that all requirements can be placed in one simple sequence. In reality, some are legally mandatory, some block the launch and others mainly improve user convenience. A single number may not describe these differences.
What is the MoSCoW method?
MoSCoW is a technique for prioritising requirements, objectives and project scope. Its name comes from the first letters of four categories:
- Must have – essential for the solution,
- Should have – important and expected if possible,
- Could have – desirable if time and resources allow,
- Won't have this time – deliberately excluded from the current release.
The letters “o” do not represent separate categories. They are included only to make the acronym easier to remember.
MoSCoW does not create a perfect ranking from first to last. It helps the team agree on the degree of necessity and prepare a scope that can realistically be delivered within the available time and budget.
Must have – non-negotiable requirements
The Must category contains elements without which the project cannot achieve its basic purpose. Their absence means that the solution cannot be launched, fails to meet legal obligations or does not deliver minimum value to the user.
Examples may include:
- user login when the service cannot operate without accounts,
- payment processing in an online store,
- a legally required function,
- protection of critical data,
- an integration required for the core process,
- the ability to store and retrieve essential information.
A useful control question is: does the project still make sense without this element? If the answer is yes, although the solution would be less convenient, the feature is probably not a Must.
How can false Must requirements be identified?
The most common mistake is assigning Must to requirements that are simply important to a particular person. Statements such as “we have always done it this way”, “the customer expects it” or “management likes it” are not sufficient proof that a feature is essential.
The team should examine the consequence of omission:
- Would the solution break the law?
- Would the core task become impossible?
- Would launch be technically impossible?
- Would the business risk become unacceptable?
- Would the product lose its fundamental value?
If the main consequence is reduced convenience, additional manual work or a temporary workaround, the requirement may belong in Should rather than Must.
Should have – highly important but deferrable
Should requirements deliver significant value and should be included when time and resources permit. Their absence is noticeable but does not make the entire project fail.
Examples include:
- automatic reporting when a manual report is temporarily possible,
- an additional payment method when the primary method works,
- an integration that accelerates a process but does not prevent manual completion,
- advanced search filters when basic search remains available,
- a function that makes high-volume operation easier.
Should does not mean unimportant. It means that an acceptable workaround exists or that the feature can be postponed without destroying the goal of the current release.
Could have – valuable enhancements
The Could category contains desirable but non-essential elements. They may improve convenience, appearance or attractiveness, but their absence does not significantly affect the core operation.
Examples include:
- additional visual themes,
- extended personalisation,
- alternative data views,
- minor automation,
- features useful to a small group of users,
- improvements that can be added easily in a later iteration.
Could is useful for planning. It creates a ready list of tasks the team can take on when critical work finishes early or additional capacity becomes available.
Won't have this time – a deliberate postponement
The Won't category is often misunderstood as a place for rejected or unimportant ideas. In reality, it means: we will not deliver this now, but we are deliberately preserving it for the future.
The requirement may still have value but not fit the current budget, deadline or release objective. Recording it prevents future needs from disappearing and having to be rediscovered later.
It is helpful to document the reason, for example:
- cost is too high at the current stage,
- the required integration is not ready,
- the current user base is too small,
- more data must be collected first,
- the need has not yet been validated,
- delivery is planned for a later release.
This category is what makes MoSCoW more than a scope-cutting tool. It also protects valuable ideas from being completely lost.
Won't does not mean never
The full phrase should be “Won't have this time”. The words “this time” matter because they limit the decision to a particular release, sprint, stage or planning period.
Without that clarification, stakeholders may fear that a Won't classification means permanent deletion. They will then defend every feature and try to move it into Should or Must.
A good practice is to set a review point for Won't requirements. They may be reconsidered before the next release, after new user data is collected or once key integrations are completed.
How should a MoSCoW workshop be run?
The strongest results come from a joint session involving different perspectives. Depending on the project, participants may include:
- the product owner,
- a business representative,
- a business analyst,
- a UX designer,
- a developer or architect,
- a sales representative,
- an operational employee,
- a legal or security specialist.
The workshop may follow these steps:
- Agree on the objective of the current release.
- Review the complete list of requirements.
- Assign initial categories.
- Discuss disputed items.
- Check whether the Must scope is realistic.
- Record the reasons for key decisions.
- Confirm the scope with accountable stakeholders.
Without a shared objective, MoSCoW can become another competition between departments. Participants must evaluate features from the perspective of project success rather than only their own area.
Define the project objective before the priorities
Correct classification is impossible without knowing what the current stage is expected to achieve. The same function may be a Must in one release and a Could in another.
For example, if the purpose of the first version is to test whether users want to buy a product, an advanced reporting dashboard may be Won't. If the project is a regulatory reporting system, reporting may be the most important Must.
Before the workshop, define:
- the release objective,
- the main user group,
- the core process,
- the deadline,
- the budget and available capacity,
- the main risks,
- the criteria for success.
How many requirements can be Must?
There is no universal percentage for every project, but Must requirements should not consume all available time. If everything is essential, the team has no margin for technical problems, defects, absence or unexpected dependencies.
A realistic scope should leave space for uncertainty. If delivering all Must items requires one hundred per cent of the available capacity, the plan is highly vulnerable to delay.
The team should also look for simplification. A partially manual process may be enough instead of full automation in the first release. A basic data import may temporarily replace a complete integration.
How should priority disputes be resolved?
Disagreement is a normal part of prioritisation because participants see different risks and values. It becomes a problem when the discussion relies only on hierarchy or strong opinions.
Useful questions include:
- What value will users lose without this feature?
- What is the legal or financial risk?
- Is a temporary workaround available?
- How many users need the feature?
- How often will it be used?
- What is the delivery cost?
- Does it block other work?
- What evidence supports its importance?
Decisions should be based on consequences, not on who argues most loudly.
MoSCoW and technical dependencies
Business priority does not always determine technical sequence. A Could feature may require architectural preparation now to avoid rebuilding the entire system later.
Likewise, a Must feature may depend on several less visible technical tasks. The classification should therefore include more than user-facing functionality. It should also cover:
- security,
- data migration,
- monitoring,
- performance,
- backups,
- integrations,
- infrastructure.
Analysts and technical team members should explain which tasks are essential to deliver the declared Must items.
MoSCoW in Agile projects and sprints
MoSCoW can be applied to the whole product, a release, a sprint or a single process. The important point is to define the time horizon covered by the classification.
In Agile projects, categories are not permanent. Priorities may change after:
- user testing,
- changes in market conditions,
- new risks,
- data analysis,
- deadline changes,
- the discovery of technical dependencies.
MoSCoW should not replace regular backlog management. It is a decision-support tool rather than a one-time label.
Example: applying MoSCoW to an online store
Assume that a team is preparing the first version of an online store.
Must have
- product browsing,
- a shopping basket,
- order placement,
- a basic payment method,
- purchase confirmation,
- protection of user data.
Should have
- several payment methods,
- shipment tracking,
- a customer account,
- automatic invoices.
Could have
- a favourites list,
- product comparison,
- advanced recommendations,
- extended personalisation.
Won't have this time
- a loyalty programme,
- a mobile application,
- international sales,
- integration with a large marketplace.
This does not mean that a loyalty programme is unimportant. It means that it is not required to validate the basic sales model in the first release.
Common mistakes when using MoSCoW
Everything becomes Must
If most requirements receive the highest category, the method has not been applied correctly. The minimum successful scope must be reconsidered.
No clear “this time”
Without a defined release, Won't will be interpreted as permanent rejection.
Classification without the technical team
Business stakeholders may not understand implementation cost, dependencies and technical risk.
No explanation for decisions
After several weeks, participants may forget why a requirement was postponed. A short explanation prevents repeated arguments.
No later review
Priorities may change and should be revisited when new information becomes available.
Confusing priority with implementation order
A Must item does not always have to be built first. Sequence may depend on architecture, team availability and dependencies.
How should decisions be documented?
For each requirement, it is useful to record:
- the MoSCoW category,
- a short explanation,
- the person accountable for the decision,
- the date of classification,
- conditions that would change the priority,
- the next review date.
The documentation does not need to be extensive. One or two sentences are often enough to prevent future misunderstanding.
How does MoSCoW help teams reach agreement?
The method does not remove conflicting interests, but it creates a shared language. Instead of debating whether a feature is “very important”, the team examines the consequence of its absence and whether it can be postponed.
Main benefits include:
- clearer scope boundaries,
- easier release planning,
- fewer hidden expectations,
- preservation of future ideas,
- more transparent decisions,
- fewer disputes near the end of the project.
Agreement does not mean that everyone receives every requested feature. It means that everyone understands what will be delivered, what may be delivered and what has deliberately been postponed.
MoSCoW does not replace value and cost analysis
The category alone does not show delivery cost or business value. Two Should requirements may differ in effort by a factor of ten.
MoSCoW should therefore be combined with:
- effort estimates,
- business value assessment,
- risk analysis,
- user data,
- dependency mapping,
- release planning.
The method provides a framework for discussion, but it does not remove the need for analysis.
When is MoSCoW most useful?
The technique works particularly well when:
- the desired scope is larger than the available time,
- many stakeholders are involved,
- a minimum viable product must be defined,
- the scope of a release must be agreed,
- postponed ideas need to be preserved,
- the team needs a simple language for discussing trade-offs.
It is less effective when categories are assigned by one person without discussion or when decisions are not connected to a specific goal and deadline.
Summary
MoSCoW is a simple but effective project prioritisation method. It separates essential, highly important, optional and deliberately postponed requirements.
Its major advantage is that future needs are not removed from the list. The Won't category protects valuable requirements while preventing the current scope from becoming overloaded.
Effective use requires a clear release objective, participation from business and technical teams, a limited Must scope and regular review of decisions.
Good prioritisation is not about marking everything as important. It is about choosing what must be delivered now and naming honestly what can wait.
