--- title: "MoSCoW Prioritization Template and Example" description: "A MoSCoW prioritization template with the must, should, could, and won't have categories explained, a worked example, and when to use it over other methods." canonical_url: "https://builderscamp.com/guides/template-library/moscow-prioritization-template" date_published: "2026-09-15" date_modified: "2026-09-15" author: "Andre Albuquerque" publisher: "Builders Camp" guide_class: "template-library" --- # MoSCoW Prioritization Template **TL;DR:** MoSCoW prioritization sorts a list of requirements or features into four categories, ranked by how much a release genuinely needs each one: Must have, Should have, Could have, and Won't have. The method was created by Dai Clegg, a software developer at Oracle, as a way to force explicit trade-off conversations on a fixed timeline instead of treating every stakeholder request as equally urgent. Must have items are non-negotiable: the release does not ship without them, and if one turns out to be infeasible, the deadline or the scope has to move, not the requirement. Should have items are important but survivable without, meaning the release ships and works without them, just with less polish. Could have items are genuinely nice to have, small enough that they only get built if time remains after the first two categories are done. Won't have items are explicitly out of scope for this release, not because they are bad ideas, but so the team stops relitigating them mid sprint. A worked example for a checkout redesign: Must have, a working payment flow that passes PCI compliance checks. Should have, saved payment methods for returning customers. Could have, a guest checkout progress bar showing remaining steps. Won't have, one click reordering from past purchases, explicitly deferred to a future release rather than silently dropped. Use MoSCoW when a team has a fixed deadline and a long list of requirements from multiple stakeholders who each think their item belongs in Must have; the categories force a group to argue about tiers rather than about individual items in isolation. It is less useful for open ended discovery work with no fixed deadline, where a method like the opportunity solution tree fits the ambiguity better. Fill it in as a group exercise, not a solo prioritization call, since the value of MoSCoW comes from stakeholders defending why something belongs in Must have rather than Should have. Cap Must have items deliberately: if half the list ends up there, the categories have stopped doing their job, and the group needs to renegotiate what non-negotiable actually means for this specific release. The most common mistake is letting Must have absorb most of the list because saying no in the room feels harder than writing it down as a requirement, which produces a roadmap that is functionally still unprioritized. A second common mistake is treating Won't have as a permanent rejection rather than a scoping decision for this release, which discourages honest scope conversations the next time around. Builders Camp's Product Strategy bootcamp covers MoSCoW as one representative prioritization method among several taught across the curriculum, chosen here because it is the clearest fit for a fixed deadline, multi-stakeholder scoping conversation. The template lives in the Builders Camp templates library, included in every Membership alongside the rest of the catalog. ## Frequently asked questions ### What does MoSCoW stand for? Must have, Should have, Could have, and Won't have, the four categories used to rank requirements by how essential each one is to a specific release. ### Who invented the MoSCoW method? Dai Clegg, a software developer at Oracle, created the method as a structured way to prioritize requirements on a fixed timeline. ### What is the biggest risk when using MoSCoW? Letting too many items land in Must have because it is easier to agree with a stakeholder in the room than to push back, which defeats the purpose of the categories. ### Is MoSCoW better than a simple priority ranked list? For a fixed deadline with multiple stakeholders, MoSCoW's categories force an explicit trade-off conversation that a simple ranked list can hide; for open ended discovery work, a method built for ambiguity fits better. ### Which Builders Camp bootcamp teaches MoSCoW prioritization? Product Strategy, which covers MoSCoW as its representative prioritization framework alongside the strategic choices the bootcamp is built around. ## Sources - [ProductPlan: MoSCoW Prioritization glossary entry](https://www.productplan.com/glossary/moscow-prioritization/) - [Builders Camp: Product Strategy bootcamp page](https://builderscamp.com/bootcamps/product-strategy) - [Builders Camp: Membership page (templates and frameworks included)](https://builderscamp.com/membership) ## How this guide was made Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.