Resolving Stakeholder Priority Conflicts with MoSCoW

How to settle MoSCoW prioritization disputes and Must-have inflation with decomposition, dependency checks, an effort limit and an escalation path.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Stakeholder priority conflicts in MoSCoW most often take one shape: several people claim Must for their own items, and the Musts together exceed what the team can deliver. This skill covers resolving prioritization disagreements of that kind. The background on the categories themselves is on the MoSCoW method page, and running the session is covered in the workshop skill.

Must-have inflation is a known pattern. The DSDM handbook names "all requirements appear to be Must Haves" as one of the problems that often confront teams, and notes that if every requirement really were a Must, the flexibility MoSCoW depends on would disappear. Its diagnosis is specific: believing everything is a Must "is often symptomatic of insufficient decomposition of requirements". That gives the facilitator a first move that does not require anyone to lose.

The stakes of letting inflation stand are concrete. DSDM recommends typically no more than 60% of the effort for Musts (DSDM: MoSCoW prioritisation), because the Should and Could effort is the contingency that protects the guarantee. Eduardo Miranda's simulations found that under these rules a team "ought to be able to deliver all Must Have features" for underestimations of up to 100% with very high probability (Moscow Rules). A list that is mostly Must removes that protection.

Some disputes are not about definitions at all. ProductPlan lists team bias for or against an initiative and missing stakeholders among MoSCoW's main pitfalls. This skill therefore pairs the analytical tools (splitting, dependency checks, cost comparison) with a process tool: an escalation path agreed before any dispute starts.

Each resolved dispute should leave a record: the item, the tests applied, the answers given, the outcome and who decided. That record is what stops the same argument returning at the next increment, and it lets a stakeholder whose item moved down see exactly what would move it back up.

How It Works

The skill uses five tools in order, from the least confrontational to the most.

Decomposition comes first. A disputed Must is split into parts and each part is tested separately. Often only one part passes the Must test, which gives the stakeholder the part they actually need on the date. The DSDM handbook also allows different priorities on acceptance criteria, so a disputed quality level can be split into a Must limit and a Should target.

The consequence tests come second. DSDM gives three: what happens if the requirement is not met, would you stop the deployment if told the night before it could not be delivered, and is there a workaround? The handbook assigns the burden of explanation to the business: the Business Visionary or an empowered Business Ambassador explains why a requirement is a Must, and the rest of the team is expected to question Musts that are not obvious.

Dependencies come third. A Must cannot depend on anything other than a Must. A stakeholder who wins Must for an item that depends on a Could has created a hidden risk, and resolving it forces a choice.

Cost comparison comes fourth. For a Should vs Could dispute, DSDM suggests comparing the cost of the workaround with the cost of delivering the requirement, including the cost of doing it later. That turns an argument about importance into an argument about numbers the finance or operations owner can supply.

Escalation is last. DSDM advises agreeing the escalation route early, for example from business ambassador and analyst to business visionary to sponsor, with the level of empowerment at each step. Any dispute that the first four tools do not settle within the time limit goes up that route with both positions written down.

Step-by-Step Guide

Step 1: Agree the rules before the dispute

Before any prioritization session, agree the MoSCoW definitions, the Should vs Could criteria, who explains a proposed Must and the escalation route. ProductPlan recommends deciding how disagreements will be settled before the analysis starts. Write the rules down and get the sponsor to endorse them. Agreement made in calm conditions is much easier to hold to than agreement reached mid-argument.

Step 2: Make the capacity visible

Show the effort available in the timeframe and the effort already claimed as Must. Put the DSDM guideline of typically no more than 60% Must effort next to it. When the claimed Musts exceed the line, the conflict is visible as arithmetic, and nobody has to call a colleague's item unimportant. Every later decision refers back to this picture.

Step 3: Split each disputed Must

Take the largest disputed Must first and break it into parts, including its acceptance criteria. Run the consequence test on each part with the stakeholder who proposed it. Keep the parts that pass as Musts and place the rest as Should or Could. Repeat for the next largest until the Must effort is within the agreed level or no further splits are possible.

Step 4: Test the remaining Musts and their dependencies

For each Must that remains in dispute, ask the proposer to answer the three DSDM tests aloud. Check each Must's dependencies and resolve any that point to lower categories. Ask the team whether a workaround exists that the proposer has not considered. Record the answer to each test, since the record is what makes the decision stick later.

Step 5: Compare costs for Should vs Could disputes

Where the dispute is between Should and Could, estimate the cost of the workaround and the cost of delivering the item now and later. Ask the owners of those costs, such as operations or finance, to supply the figures. Apply the agreed Should vs Could rule to the result. Keep this step short, because a Should vs Could call carries less risk than a Must call.

Step 6: Timebox and escalate what remains

Give each remaining dispute a short fixed time. DSDM describes a five-minute rule that parks an unresolved disagreement as an open issue. Send each open issue up the agreed escalation route with both positions, the test answers and the effect on the Must share. Set a date for the decision so the plan is not held up.

Step 7: Record and communicate every decision

Record each resolved dispute with its outcome, the tests applied and who decided. Tell every stakeholder whose item moved, and tell them what would change the decision in a later increment. Keep the Won't haves visible so the requests are not reintroduced informally. Review the decisions at the next increment boundary, when some items will rightly move up.

Best Practices

• Split before you argue. Decomposition often gives the stakeholder the part that matters on the date and removes the conflict without a loser.
• Make the business explain its Musts. The DSDM handbook gives that job to the Business Visionary or an empowered Business Ambassador, and the team is expected to question Musts that are not obvious.
• Argue from the tests. Asking "what happens if this is not met?" moves the discussion from a person's standing to a consequence the room can check.
• Resist padding. The handbook warns that pressuring a team to guarantee Musts, Shoulds and Coulds together "usually results in padded estimates". Protect the contingency instead.
• Tell people what would change the decision. A stakeholder who knows their item returns as a candidate at the next increment accepts a Won't have more readily.
• Look for missing voices. ProductPlan notes that leaving out relevant stakeholders puts items in the wrong categories, so check who is absent before treating a dispute as settled.

Common Mistakes

• Averaging the disagreement: Settling a Must vs Could dispute at Should satisfies nobody and hides the real risk. Apply the tests and decide.
• Letting seniority decide: A category set by the most senior voice will be reopened as soon as that person leaves the room. Use the agreed escalation route and record the reasons.
• Raising capacity on paper: Accepting every Must and assuming the team will absorb it removes the contingency the method depends on. Keep the Must effort within the agreed level.
• Resolving disputes in private: Side deals between one stakeholder and the delivery team undermine the list. Bring every change through the same process.
• Skipping the follow-up: A decision nobody communicated returns as a new dispute. Tell every affected stakeholder the outcome and the reason.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: MoSCoW Method

Related Skills

• Facilitating a MoSCoW Prioritization Workshop
• Categorizing Requirements into MoSCoW Categories
• Defining MVP Scope with MoSCoW
• Applying MoSCoW to Project and Software Requirements
• Building a MoSCoW Roadmap for Phased Delivery
• MoSCoW vs RICE, ICE and WSJF

Sources

• DSDM Agile Project Framework handbook (PDF)
• Agile Business Consortium: DSDM handbook, MoSCoW prioritisation
• Eduardo Miranda: Moscow Rules, a quantitative exposé
• ProductPlan: MoSCoW prioritization

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.