MoSCoW
Must, Should, Could, Won't — negotiate scope explicitly against the deadline.
Table of Contents
History & Origins
MoSCoW was created by Dai Clegg at Oracle in the 1990s as a prioritisation method for rapid application development (RAD). It was later adopted into the Dynamic Systems Development Method (DSDM), one of the early agile frameworks. The acronym stands for Must-have, Should-have, Could-have, and Won't-have, with the lowercase 'o's added for readability. The method became a standard tool in agile project management, release planning, and scope negotiation, particularly for fixed-deadline deliveries. MoSCoW is now used alongside or instead of story-point estimation in many agile organisations, because it communicates priority to non-technical stakeholders more clearly than velocity metrics. Clegg developed MoSCoW to solve a problem he observed at Oracle: project scope was negotiated implicitly, with stakeholders adding requirements throughout the project, and the team cutting features silently at the end to meet the deadline. By making scope negotiation explicit (Must, Should, Could, Won't), MoSCoW forced the conversation about what wouldn't ship before the build began, rather than after the deadline was missed. The framework is complementary to the Project Triangle (which names the fixed constraint) and to OKRs (which define the outcomes), and it is particularly valuable for fixed-deadline deliveries where scope must be negotiated against time. Today, MoSCoW is used in ERP migrations, commerce replatforms, and any delivery where the go-live date is fixed and scope must be managed explicitly.
Core Concept
MoSCoW classifies requirements into four priorities: Must-have (the minimum viable release without which the launch fails), Should-have (valuable but not critical for go-live), Could-have (stretch goals if time allows), and Won't-have (formally deferred to a future release). The framework makes scope negotiation explicit against time and budget, so there's no silent scope creep that inflates cost and delays value. The key principle is that Won't-have is a formal decision, not a vague aspiration: it's documented and communicated to stakeholders, so expectations are managed before the build begins rather than after the deadline is missed. MoSCoW is complementary to the Project Triangle: the triangle names the fixed constraint, and MoSCoW negotiates scope within it. The framework also argues that the Must-haves define the minimum viable release, and that the Should-haves and Could-haves are negotiated against the remaining time and budget. The key discipline is that the Won't-haves are communicated to stakeholders upfront, so there's no expectation gap at go-live. The framework also distinguishes between a Must-have (the launch fails without it) and a Should-have (the launch is better with it but doesn't fail without it), which is a test of criticality, not of value. A Should-have can be highly valuable but still not a Must, because the launch can succeed without it.
B2B Application Guide
In B2B companies, MoSCoW prioritises ERP and commerce features for go-live. Musts define the minimum viable release (core purchasing, warehousing, BOM revision control). Shoulds are valuable but not critical (vendor portals, advanced forecasting). Coulds are stretch (mobile dashboards). Won'ts are formally deferred (AI recommendations). The framework protects a release's integrity by agreeing upfront what won't ship, rather than cutting late under pressure. Resourcing follows the priority: Musts get the best people and budget, Won'ts get nothing until the next cycle. For technology selection, it locks the Must-have modules for go-live and defers the Shoulds and Coulds, preventing the over-build that inflates licensing opex and BOM complexity without delivering proportional value. For supply chain, MoSCoW prioritises WMS features: Musts are core receiving, putaway, and picking; Shoulds are advanced forecasting and slotting; Coulds are mobile dashboards; Won'ts are AI-driven automation. For merchandising, MoSCoW prioritises assortment features: Musts are core catalog and pricing; Shoulds are private-label management; Coulds are AI-driven recommendations; Won'ts are marketplace integration. For hiring, MoSCoW prioritises roles: Musts are core engineering and operations; Shoulds are specialist roles; Coulds are nice-to-have roles; Won'ts are future-cycle roles. For vendor management, MoSCoW prioritises vendor integrations: Musts are critical vendor connections; Shoulds are important but non-critical; Coulds are stretch; Won'ts are deferred.
Step-by-Step Implementation
Step 1: List all requirements. Write down every feature, module, and integration requested for the release. Step 2: Classify each as Must, Should, Could, or Won't. Must: the launch fails without it. Should: valuable but not critical. Could: stretch if time allows. Won't: formally deferred. Step 3: Confirm the Musts. Review the Must list with stakeholders and confirm each is truly critical (the launch fails without it). Step 4: Lock the Won'ts. Document and communicate the Won't list to stakeholders, so expectations are managed upfront. Step 5: Estimate the Musts. Confirm the Musts can be delivered within the fixed time and budget. If not, re-classify or negotiate. Step 6: Add Shoulds if time allows. After the Musts are confirmed, add Shoulds in priority order until the time and budget are full. Step 7: Add Coulds if time remains. If the Shoulds are done and time remains, add Coulds. Step 8: Track at each milestone. At each milestone, confirm the Musts are on track and the Shoulds/Coulds are negotiated against remaining time. Step 9: At go-live, record what shipped. Document what shipped (Musts, Shoulds, Coulds) and what was deferred (Won'ts), so the next release inherits realistic priorities.
Common Pitfalls & How to Avoid Them
Pitfall 1: Everything is a Must. Stakeholders classify everything as critical, and the Must list is too large to deliver. Avoid by testing each Must: would the launch actually fail without it? Pitfall 2: Not locking the Won'ts. The Won't list is vague, and stakeholders expect features that won't ship. Avoid by documenting and communicating the Won't list upfront. Pitfall 3: Silent scope creep. Requirements are added without re-classifying, and the Must list grows silently. Avoid by requiring re-classification for every addition. Pitfall 4: Not tracking at milestones. The Musts are assumed on track, and a Must is discovered late to be at risk. Avoid by tracking the Musts at each milestone. Pitfall 5: Cutting Musts late. A Must is cut to meet the deadline, and the launch fails because the critical feature is missing. Avoid by negotiating Shoulds and Coulds first, not Musts. Pitfall 6: Not documenting what shipped. The release ships, but the scope ledger is lost, and the next release starts from scratch. Avoid by documenting what shipped and what was deferred.
Extended Real-World Example
An ERP go-live was scoped using MoSCoW. 12 Musts were locked (core purchasing, warehousing, BOM control, financial close). 9 Shoulds were scheduled (vendor portal, advanced forecasting, mobile approvals). 6 Coulds were stretch (AI demand planning, predictive analytics). 4 Won'ts were formally deferred (social commerce, marketplace integration). The launch shipped on date with all 12 Musts and 6 of 9 Shoulds, protecting the go-live without silent scope cuts. The 4 Won'ts were communicated to stakeholders as deferred, not dropped, and the release-level scope ledger recorded what shipped, what was deferred, and why, so future programs inherited realistic priorities. Over the 10-month implementation, the MoSCoW scope was managed explicitly. Month 1: 31 requirements were classified (12 Musts, 9 Shoulds, 6 Coulds, 4 Won'ts). The Won't list was communicated to stakeholders in a steering meeting, with a clear statement that social commerce and marketplace integration would not ship in this release. Month 3: A new requirement (EDI compliance for a key customer) was added. It was classified as a Must (the customer's contract required it), and a Should (advanced forecasting) was re-classified as a Could to make room. Month 5: The Musts were confirmed on track, and 6 of 9 Shoulds were started. Month 7: A Must (financial close) was at risk due to a vendor delay. The steering committee added cost (a contractor) rather than cutting the Must, and the Must was delivered on time. Month 9: All 12 Musts were delivered, 6 of 9 Shoulds were delivered, 2 of 6 Coulds were delivered, and the 4 Won'ts were deferred. The go-live shipped on date with a functional ERP that met all critical requirements. The scope ledger recorded: 12 Musts shipped (100%), 6 Shoulds shipped (67%), 2 Coulds shipped (33%), 4 Won'ts deferred (0%). The 3 undelivered Shoulds and 4 undelivered Coulds were rolled into the next release, with the MoSCoW classification carried forward. The 4 Won'ts were re-assessed for the next release: 2 were re-classified as Shoulds (market demand had grown), and 2 remained Won'ts. The MoSCoW practice prevented the most common failure: silent scope cuts at the end of the project. Because the Won't list was communicated upfront, stakeholders didn't expect the deferred features at go-live, and the launch was perceived as complete rather than incomplete. The scope ledger also helped the next release start with realistic priorities: the 3 undelivered Shoulds were the first priorities, and the team didn't re-litigate the scope decisions from the previous release.
Measuring Success
MoSCoW success is measured by whether the Musts shipped and whether the Won'ts were communicated upfront. The key indicators are: Must delivery rate (the percentage of Musts that shipped, which should be 100%), Should delivery rate (the percentage of Shoulds that shipped, which should be 60-80%), and Won't communication (whether the Won't list was documented and communicated before the build, which should be yes). In practice, these are tracked by the scope ledger, which records what shipped and what was deferred. The ultimate test is whether the go-live was perceived as complete: did stakeholders expect the deferred features, or were they managed upfront? If the Must delivery rate is below 100%, the launch was incomplete, and the Must classification was either wrong or the delivery was under-resourced. If the Won't communication was missing, stakeholders expected features that didn't ship, and the launch was perceived as incomplete despite the Musts being delivered. A healthy MoSCoW practice produces a 100% Must delivery rate, a 60-80% Should delivery rate, and a documented Won't list that was communicated before the build, with the scope ledger carried forward to the next release.
Framework Visualizations
Data-driven graphics showing how MoSCoW is applied to real B2B data.
Explore Further
Explore the Full Portfolio
This is the complete portfolio of Sufi Khan Sulaiman, a technology leader specialising in B2B commerce and digital automation. Start from the Home page for the overview, then move through two decades of career experience across FLIR Systems, Lorex Technology, and 1c Platform, and the full catalogue of project case studies spanning headless commerce migrations, AI recommendation engines, and multi-channel fulfilment systems.
The skills and certifications page maps the technical and leadership capabilities behind the work, while the articles and the knowledge base break down the thinking into actionable frameworks. For hands-on learning, the tutorials and applications sections cover practical builds from front-end fundamentals to full-stack web apps.
For consulting engagement, the expertise page outlines service offerings, the ecommerce hub covers platform architecture and automation strategy, and the ecommerce guide (PDF) is a downloadable 55-page field manual. When you are ready to talk, the contact page is the direct line.