Skip to content
BP #3: MoSCoW

BP #3: MoSCoW

Immediately after concept lock, split every planned feature into four buckets: Must have, Should have, Could have, Won’t have. Build only from the Must list until it is done.


Why It Works

Without an explicit priority list, every feature feels equally important when you are building it. The last hour of a jam reveals which ones actually mattered. MoSCoW forces that judgment to happen at the start, when the cost of being wrong is low, rather than at the end, when it is not.

Kaitila describes the same split without the formal name: essential features like movement, controls and a win state get built first, everything else gets saved for later or cut. [2] The developers who kept that distinction clear from the start finished with less stress. Those who did not reported having to cut things they had already built. [2]


The Four Buckets

Priority Meaning in a jam
Must have Game does not function without this. Movement, win/loss state, core mechanic.
Should have Improves the experience significantly. Build after all Musts are done.
Could have Nice to have. Touch only if time remains and Musts and Shoulds are complete.
Won’t have Agreed cut. Not this jam. Write it down so it stops coming up.

How to Apply

Right after concept lock:

  1. List every feature the team wants
  2. Each person assigns a priority: M, S, C or W
  3. Discuss disagreements only — skip anything everyone agrees on
  4. Final list gets written somewhere visible

Must Haves become the build order for day 1. At the pivot gate (hour 24) the Should and Could lists are the first things cut if Must Haves are not done.


Methodology Connection

Methodology Connection

MoSCoW prioritization is a standard tool in software development for deciding what gets built when resources are constrained. [5] In a 48-hour jam the constraint is time. The method applies without modification: Musts ship, the rest depends on what survives the gate at hour 24.


Related