MoSCoW puts every feature request in one of four buckets. Must have. Should have. Could have. Won't have. Snap the board and the scope decision becomes a shareable artifact.
Use MoSCoW at the start of a project or sprint to define scope, during a planning session when stakeholders can't agree on what's in or out, or when a release date is fixed and the team needs to decide what to cut.
MoSCoW is especially valuable in stakeholder-heavy environments where 'we can't do everything' needs to be made tangible. Seeing a stakeholder's favorite feature move to 'Could Have' on a physical board carries more weight than reading it in a document.
Non-negotiable requirements for the release to be viable. If any Must Have is missing, the release should not ship. Apply a strict filter: 'would we delay the release if this wasn't in?' If the answer is no, it's not a Must Have. Most teams discover their Must Have list is shorter than they assumed.
Important requirements that significantly increase value, but the release can ship without them. Should Haves are the first candidates for a follow-up sprint. They're not nice-to-haves, they're next-sprint priorities.
Desirable but genuinely optional features that can be dropped without significant impact. These are included only if time and resources allow. Be honest, items that look like Could Haves often get sneaked into Must Have under deadline pressure.
Explicitly out of scope for this release. Not forever, 'this time' is the key phrase. This column makes the cut explicit and gives stakeholders a legitimate place for their deprioritized requests. It's not rejection; it's a scheduled conversation.
Write every feature, requirement, or task on a sticky. Include stakeholder requests that aren't yet committed. Get everything visible before sorting.
Must Have, Should Have, Could Have, Won't Have (This Time). Leave generous space in each column.
For each item, ask: 'Would we delay the release if this wasn't included?' Only if the unanimous answer is yes does it go in Must Have. Challenge every item that lands here, teams routinely over-populate Must Have and can't figure out why releases slip.
Place remaining stickies in Should Have, Could Have, or Won't Have. The distinctions force conversations about what's genuinely important vs. what's merely wanted.
Estimate the effort for all Must Have items. If it exceeds 60% of available capacity, you have too many Must Haves. Move the least-critical items to Should Have, releasing late because you over-scoped the Must Have column is the most common release failure mode.
Snap the board with BoardSnap. The AI reads all four columns and outputs the scope decision as a structured document, shareable with every stakeholder who needs to see what's in and what's out.
MoSCoW works because making scope decisions explicit and visible changes the conversation. Stakeholders who see their feature in 'Could Have' on a physical board in a joint session understand the decision differently than stakeholders who read it in a changelog. The whiteboard format puts everyone in the same room with the same visible artifact, that shared context reduces the 'but I thought we said...' conversations that happen after digital-only sessions.
BoardSnap preserves the session output. Snap the board and the AI reads all four columns, every item in its exact bucket, and outputs the scope decision as a shareable artifact with the rationale preserved in the board's context.
Dai Clegg developed MoSCoW in 1994 while working at Oracle, as part of the DSDM (Dynamic Systems Development Method) framework. It's now widely used outside DSDM in agile, waterfall, and hybrid project management contexts.
A common heuristic: Must Haves should require no more than 60% of available capacity, leaving room for Should Haves and buffer. Should Haves typically take 20 to 30% of capacity. Could Haves are only included if there's remaining time. Won't Haves are everything else. If your Must Haves alone exceed 100% of capacity, you have a scope problem, not a prioritization problem.
The impact/effort matrix ranks items by expected value and estimated cost. MoSCoW makes binary scope decisions: is this in or out for this release? They're complementary, run the impact/effort matrix to prioritize your backlog, then use MoSCoW to make firm scope commitments for a specific release.
Yes, but every addition to Must Have requires removing something of equivalent effort from Must Have or extending the timeline. Never add to Must Have without an explicit trade-off conversation. The MoSCoW board, preserved by BoardSnap, is the record of what was agreed, which makes scope creep conversations factual rather than political.
No exporting, no transcription. Snap the board, get the action plan.