MoSCoW classifies requirements as Must, Should, Could, and Won’t Have this time. The classification is checked against the goal, dependencies, risks, and available capacity.

1. 1

   Frame

   Clarify release and Must test

   

   Goal

   A binding basis for classification is agreed.

   Inputs for this step

   • Release goal and date
   • Capacity, constraints, and quality boundaries

   Actions

   • record timeframe and delivery goal
   • agree the Must test with examples
   • clarify mandate and dependencies

   Output

   Prioritization frame

   Without time and capacity, the category loses force.

   Quality check

   Won’t explicitly means Won’t Have this time. Must describes a real delivery boundary, not mere importance.

   Pitfall

   Everything important becomes Must. Ask whether the release would be nonviable, unsafe, or illegal without the item.

   Timing: 10 minutes

2. 2

   Classify

   Sort items into four categories

   

   Goal

   Every item has a reasoned category.

   Inputs for this step

   • Backlog items
   • Dependencies, risks, and value

   Actions

   • bring items to comparable granularity
   • assign Must, Should, Could, or Won’t Have this time
   • record rationale and disagreement

   Output

   Categorized backlog

   Won’t describes a deliberate deferral in the current period.

   Quality check

   Every item is assigned exactly once. Should has no valid Must rationale.

   Pitfall

   Epics and detail tasks are compared directly. Bring items to a common granularity or plan separate levels.

   Timing: 20–30 minutes

3. 3

   Constraints

   Check Musts against capacity and dependencies

   

   Goal

   A realistic core scope is visible.

   Inputs for this step

   • Categorized backlog
   • Capacity and dependency information

   Actions

   • estimate effort roughly
   • check Must effort against capacity and hard limits
   • make dependencies and risks visible

   Output

   Checked core scope

   MoSCoW does not create false precision; rough sizes are enough for the boundary.

   Quality check

   Musts fit available capacity or trigger a conscious escalation. Risks and dependencies have an owner or decision.

   Pitfall

   The Must list clearly exceeds capacity. Renegotiate criteria and scope before rating further items.

   Timing: 15–20 minutes

4. 4

   Trade-offs

   Negotiate Shoulds and Coulds

   

   Goal

   Trade-offs and fallback order are explicit.

   Inputs for this step

   • Checked Must core
   • Should and Could items

   Actions

   • test Shoulds for value, pain, and workaround
   • order Coulds as explicit flexibility
   • agree descoping order under time pressure

   Output

   Negotiated flexibility

   Coulds are not promised scope.

   Quality check

   Shoulds have an acceptable temporary workaround. Coulds can go first without breaking the release goal.

   Pitfall

   Coulds become a silent promise. Mark them optional and agree the removal order.

   Timing: 15–20 minutes

5. 5

   Commit

   Document release set and Won’t

   

   Goal

   Scope, ownership, and change path are traceable.

   Inputs for this step

   • Negotiated categories
   • Release and decision data

   Actions

   • document release set with owners and assumptions
   • record Won’t rationale and possible later point
   • agree review and change rule

   Output

   Time-bound release decision

   Reassess categories when constraints change.

   Quality check

   Won’t is visible and not phrased as permanent rejection. Changes require a traceable new decision.

   Pitfall

   The list quietly reopens after the workshop. Put change path and decision criterion in the release document.

   Timing: 10–15 minutes