BoardSnap is an iOS app that reads a MoSCoW prioritization whiteboard — four columns of Must/Should/Could/Won't — and produces a structured scope document with items classified and the Won't list explicit.
MoSCoW prioritization — Must have, Should have, Could have, Won't have — is one of the most widely used prioritization frameworks because it produces a usable output even when a team can't agree on relative priority within a tier. The tiers are the deliverable: everything in 'Must have' ships for this release, 'Should have' ships if time allows, 'Could have' is a bonus, 'Won't have' is officially out of scope.
The 'Won't have' column is the most important and the most often omitted. When you write 'Won't have this time' on a whiteboard in front of the team and a stakeholder, it becomes a real commitment. Features that aren't explicitly out of scope tend to creep back in during development, because nobody can point to a document that said 'we decided not to do this.'
MoSCoW sessions on a whiteboard move fast — a team can classify 40 features in 30 minutes. The resulting board is a complete scope document. It almost never gets captured properly because the four-column layout is annoying to transcribe into a doc with the same clarity the board has.
Four vertical columns across the full width of the board: Must have (M), Should have (S), Could have (C), Won't have (W). Write the column headers large at the top. Optionally add a brief definition under each header: Must = release fails without this. Should = important but workaroundable. Could = nice if time. Won't = explicitly excluded.
Before classifying, write every candidate feature, requirement, or task on a separate sticky note. One item per note. Put them all in a pile — don't place them yet. Having all items visible before classification prevents early anchoring.
Go through the pile and pull out only the true Must Haves — the items without which the release is pointless or broken. Place them in the M column. Be disciplined: if you put everything in Must Have, the framework is useless. A healthy Must Have column is 20-30% of the total items.
Should Haves are important but there's a workaround if they don't ship. Could Haves add real value but nobody's blocked without them. Place each remaining item in S or C. The line between Should and Could is often debated — that debate is the value of the exercise.
Every item that doesn't belong in this release goes in Won't have — this time. Not 'never' — 'not this release.' This is the hardest column to fill because it requires stakeholders to formally agree that something is out. Fill it. It protects the team.
Count the story points or estimated effort of the Must Haves. If they exceed sprint capacity, you have a scope problem that MoSCoW just revealed. Some Musts need to move to Should. Mark items that moved — those movements are decisions that need to be recorded.
Open BoardSnap. Four clearly labeled columns, sticky notes in each. BoardSnap AI reads the column headers and assigns each note to its column based on position. Items near column borders are flagged.
A four-section scope document: Must Have items listed, Should Have items listed, Could Have items listed, and Won't Have items listed with a note that they're explicitly out of scope for this release. Moved items (items that shifted from Must to Should during capacity check) are noted. The output is a clear, defensible scope definition — paste it into the release plan or the top of the sprint backlog.
Forty-two features under consideration. The MoSCoW session took 45 minutes. Nine features in Must Have, fourteen in Should Have, eleven in Could Have, eight in Won't Have. BoardSnap produced the scope doc. The product lead used it as the v1 product brief sent to engineering. The first stakeholder who asked 'what about X?' was answered with the document — X was in Won't Have, agreed by the team.
A consulting team used MoSCoW to scope a three-month engagement deliverable with the client. The Won't Have column was the most valuable part of the session — it formally ruled out six features the client had mentioned but hadn't explicitly requested. BoardSnap's output became an exhibit in the engagement contract.
Yes. Won't Have is release-relative, not forever. The standard phrasing is 'Won't have this time' or 'Won't have in v1.' Future releases are a separate MoSCoW. Write 'Won't have — v1' as the column header if that helps the team understand the scope is release-bounded.
That disagreement is the most valuable output of the session — it surfaces implicit priority conflicts. Use dot voting to break ties: each stakeholder gets three Must Have votes. The top-voted items are Musts. This creates a democratic record of what the team believed was essential.
Yes. If you use four horizontal rows instead of four columns, BoardSnap reads the row labels and assigns items by row position. The layout (columns vs. rows) doesn't matter; the labels (M, S, C, W) do.
Snap the board, ship the action items in ten seconds.