Scope negotiation tool

MoSCoW Prioritization Helper

Turn four buckets into an inspectable scope guarantee: classify Must, Should, Could, and Won't Have this time under one release goal and timeframe, justify every Must with a failure test, and prove the guaranteed scope fits capacity, with effort, not item counts. This tool does not auto-label requests: the categorization is the product decision.

MoSCoW is timeframe-specific: the same requirement can be Must for the project and Should for this release.

Do the categorization yourself. This ledger never assigns, suggests, or infers a category, pasted requirements start Unclassified. Every Must needs an explicit failure reason; a workable fallback is evidence it may be Should or Could instead.

The ledger is blank on purpose, sample decisions are never pre-loaded as your scope. Paste requirements above, or load the labeled hypothetical sample to see how effort, workaround, and dependency checks behave.

Scope guarantee & contingency review

0 Must · 0 Should · 0 Could · 0 Won't this time · 0 Unclassified
Must effort share
- of none
Could contingency share
- of none
Capacity position
Scoped in-scope effort: 0 person-days (capacity unknown)

Item-count distribution only: Must 0 of 0 items. Category mix is measured by effort, never by item count.

Guaranteed minimum scope: if only these Musts ship, does the defined outcome remain usable/viable?

Autosaved locally in this browser only (key craftup:tools:moscow-scope-ledger:v1). Nothing is sent to a server. Exports contain your reasoning, rationale, workaround, effort, dependencies, timeframe, so the decision survives handoff.

# MoSCoW Scope Decision

## Decision context
Goal: Not specified
Timeframe: Not specified (release)
Capacity: Unknown
Effort unit: person-days

## Guaranteed minimum scope, Must Have
- None

## Should Have
- None

## Could Have / contingency
- None

## Won't Have this time (explicitly out of this timeframe, not rejected forever)
- None

## Unclassified (no category assigned, a real signal, not an error)
- None

## Capacity view (effort, not item count)
Must effort: 0
Should effort: 0
Could effort: 0
Won't effort (excluded from current capacity): 0
Available capacity: Unknown
Must share: - of none
Could contingency share: - of none
DSDM guidance, not a universal rule: for a typical project, MoSCoW recommends keeping Must Have work to no more than about 60% of effort and maintaining a meaningful pool of Could Have scope (often around 20%) so the plan can absorb uncertainty. Your context may differ, use the failure test and explicit capacity model rather than forcing a percentage.

## Integrity checks
- Minimum usable subset not yet judged: confirm whether the Must set alone stays usable/viable.

## Scope decision
What is guaranteed: Not recorded
What is flexible: Not recorded
What is explicitly out: Not recorded
What would trigger reprioritization: Not recorded

MoSCoW is a scope promise for one timeframe, not a score. Categories were assigned manually by the team.

MoSCoW is a scope promise, not a score

MoSCoW answers one question: for this timeframe, what scope is guaranteed, what is negotiable, and what is explicitly out? Musts form the Minimum Usable Subset, the scope without which delivery on the target date has no point. Shoulds are important and painful to omit, but the outcome survives without them. Coulds are deliberate contingency: valuable, flexible scope that absorbs uncertainty. Won't Have this time protects focus by naming what is out, with a revisit trigger instead of a silent backlog death.

Must Have

The outcome fails without it, or a verified external constraint (legal, safety, security, contract, critical dependency) makes it mandatory. Every Must records what specifically fails and whether a workaround exists.

Should Have

Important and valuable, but the core outcome can still succeed without it. Record the pain and cost of omission plus any workaround, that is what makes Should a real negotiation category instead of second priority.

Could Have

Deliberate contingency, not low value. A Could can be genuinely valuable and still not be necessary for this timeframe's minimum usable outcome. A healthy Could pool is what lets a plan bend without breaking.

Won't Have this time

Explicitly out of scope now, not never, not rejected strategy. Record the reason and the revisit trigger so deferral stays a decision.

The Must failure test

For every Must, answer: what specifically fails if this is not delivered in this timeframe? If the honest answer is a workable manual or painful fallback, official DSDM guidance treats that as evidence for Should or Could. A legal, safety, security, or contractual claim only counts when it names verifiable evidence, and mandatory scope is still separate from value ranking: a compliance Must can outrank a beloved feature without being the best product opportunity. If everything is Must, nothing is prioritized: force the test on each item rather than upgrading by seniority, customer count, revenue, or score.

Why effort matters more than item count

One 16 person-day Must plus four 2-day Coulds is 20% Must by count and roughly 67% Must by effort. Count-based warnings call that healthy; the plan has almost no flexibility. This ledger measures Must share and Could contingency share by comparable effort in one user-defined unit, against available capacity when entered, against classified in-scope effort otherwise, and says so explicitly. DSDM's typical-project guidance (about 60% Must effort ceiling, a meaningful Could pool often around 20%) appears as attributed context, never as a universal law or a blocking error.

Timeframes, dependencies, and the minimum usable subset

The same requirement can change category by timeframe. Historical data archiving can be Must for the overall migration yet Could for the first release, legitimate, not inconsistent. This ledger fixes one active scope level per decision and optionally records the overall-project category beside it.

A Must cannot depend on scope that may not ship. If guaranteed work depends on a Should, Could, or Won't item, the guarantee contradicts itself. The ledger flags every Must → non-Must dependency for human review instead of silently promoting the dependency.

The Must set must describe something shippable. Before exporting, judge the guaranteed minimum scope: if only the Musts ship, does the defined outcome remain usable? If not, revisit missing requirements or the goal itself.

When not to use MoSCoW

MoSCoW negotiates selected scope, it does not choose which investments deserve capacity (use product prioritization), compare candidates by score (see RICE and ICE, whose outputs must never auto-set categories), classify satisfaction response (see Kano, where “Must-be” means something different), sequence quarters, plan sprints, estimate work, or certify release readiness. Hand the exported scope decision to the roadmap, the PRD, and release readiness owners from there.

Use the right tool for the next decision

RICE Score Calculator

Compare candidates by reach, impact, confidence, and effort, then classify scope manually.

Kano Survey Builder

Classify satisfaction response separately, Kano Must-be is not a MoSCoW Must.

MoSCoW FAQ

What does MoSCoW mean?

MoSCoW stands for Must Have, Should Have, Could Have, and Won't Have this time. It is a scope-negotiation method for one timeframe: a promise about what is guaranteed, what is negotiable, and what is explicitly out, not a score or ranking.

What is a real Must?

A Must belongs to the Minimum Usable Subset: without it there is no point delivering on the target date, or an external constraint (legal, safety, security, contract, critical dependency) makes it mandatory. Ask: what specifically fails if this is not delivered in this timeframe? Stakeholder seniority, customer count, revenue, and RICE/ICE scores never make a Must by themselves.

Does a workaround mean it is not a Must?

Usually yes, under the official DSDM test: if a workable fallback exists, even a painful or manual one, the item is evidence for Should or Could rather than guaranteed Must scope. This ledger flags every Must with a workaround for human review and never reclassifies it automatically.

Why does CraftUp use effort rather than item count?

Because item counts lie about flexibility. One 16-day Must plus four 2-day Coulds looks healthy by count (20% Must) while Musts actually consume about 67% of effort. This tool measures category mix by comparable effort and labels counts as descriptive only.

Is 60% Must a hard rule?

No. DSDM guidance, not a universal rule: for a typical project, MoSCoW recommends keeping Must Have work to no more than about 60% of effort, with a meaningful Could pool (often around 20%) to absorb uncertainty. DSDM also describes exceptions where context is unusually well understood. This tool shows the check as attributed review context, it never blocks export or labels scope invalid.

Can a category change by release or timebox?

Yes, and that is legitimate, not inconsistency. The same requirement can be Must for the overall project, Should for this release, and Won't for this timebox. MoSCoW priorities are timeframe-specific, so this ledger records the active scope level and optionally the overall-project category alongside it.

What does Won't Have this time mean?

Explicitly outside the current timeframe, never 'never' and never a rejection of the underlying strategy. Each Won't records a reason and a revisit trigger so deferral is a decision, not an accidental omission or a promise of future delivery.

MoSCoW vs RICE/ICE?

Different decisions. RICE/ICE compare candidates to choose what deserves scarce capacity; MoSCoW negotiates already-selected scope into guaranteed vs negotiable for one timeframe. A high-RICE item can still be Could or Won't for this release, and a low-value legal requirement can be Must. Never auto-set categories from scores.

Is a Kano “Must-be” the same as a MoSCoW Must?

No, this is a classic terminology trap. Kano's Must-be describes a customer satisfaction response (absence causes dissatisfaction); MoSCoW's Must describes guaranteed delivery scope for a timeframe (absence breaks viability or a verified constraint). Never map one to the other automatically.

What if Musts exceed capacity?

Then the guarantee is internally inconsistent: guaranteed scope exceeds entered capacity. This ledger surfaces that contradiction explicitly and leaves the resolution to the team, renegotiate scope, add capacity, or split the timeframe. Nothing is auto-demoted, and no GO status is ever issued.