What This Template Is For
MoSCoW is a prioritization method that sorts requirements into four buckets: Must Have, Should Have, Could Have, and Won't Have (this time). It was created by Dai Clegg at Oracle in 1994 as part of the Dynamic Systems Development Method (DSDM) and remains one of the most widely used frameworks for scope negotiation. The full methodology, including allocation ratios and common mistakes, is covered in the MoSCoW Prioritization framework guide.
Where numeric frameworks like RICE produce a ranked list, MoSCoW produces a scoped commitment. The output is not "feature A scores higher than feature B." The output is "these 8 items ship no matter what, these 5 ship if things go well, and these 3 are explicitly cut." That makes it especially effective for fixed-deadline launches, MVP definitions, and stakeholder negotiations where you need a clear scope boundary.
This template gives you a ready-to-use MoSCoW board with columns for each category, fields for rationale and stakeholder sign-off, and a built-in scope allocation guide. For a comparison of when to use MoSCoW versus RICE versus ICE, see RICE vs ICE vs MoSCoW.
When to Use This Template
- MVP scoping. Define the minimum set of features needed to launch and test your core hypothesis.
- Fixed-deadline releases. When a launch date is immovable, MoSCoW clarifies what ships on day one versus what comes in a fast-follow.
- Stakeholder alignment. Give stakeholders explicit input on what is in vs. out. The "Won't Have" column prevents scope creep by making cuts visible and intentional.
- Sprint commitment conversations. When the team cannot fit everything, MoSCoW gives a vocabulary for negotiating scope without debating abstract priority numbers.
- Contract or client deliverables. Agencies and B2B teams use MoSCoW to set expectations on what is included in a statement of work.
- New PM onboarding. MoSCoW requires no numeric calibration. A new PM can run the exercise in their first week.
How to Use This Template
Step 1: List All Requirements (5 minutes)
Gather every feature, user story, or requirement that has been proposed. Include items from the backlog, stakeholder requests, technical debt, and discovery findings. Do not filter yet. The whole point of MoSCoW is to make the filtering visible.
Step 2: Define Allocation Targets (2 minutes)
The standard DSDM allocation is:
| Category | % of Total Effort | Rule |
|---|---|---|
| Must Have | ~60% | The release fails without these |
| Should Have | ~20% | Important but the release still works without them |
| Could Have | ~20% | Nice to have. First items cut if time runs short |
| Won't Have | 0% | Explicitly excluded from this release |
These are guidelines, not hard rules. Adjust the ratios for your context. An MVP might put 80% into Must Have and only 10% each in Should and Could. A mature product release might be 50/25/25.
Step 3: Categorize Each Item (15 minutes)
For each requirement, ask: "If we launch without this, does the release still achieve its core purpose?" If no, it is a Must Have. If yes, move to Should Have and repeat: "Is this important enough that we should actively plan for it?" If yes, Should Have. If nice-to-have, Could Have. If out of scope, Won't Have.
Record the rationale for each placement. This is critical for stakeholder discussions later.
Step 4: Validate Effort Allocation (3 minutes)
Add up the effort estimates for each category. If Must Haves exceed 60% of your capacity, something needs to move down or the timeline needs to change. This is the most important calibration step. If everything is a Must Have, the framework is not doing its job.
Step 5: Get Sign-off
Share the categorized list with stakeholders and engineering leads. Confirm Must Haves and get explicit agreement on Won't Haves. Silence is not agreement. Ask each stakeholder to confirm the Won't Have list out loud.
The Template
Copy this into your planning tool.
Project: [Project or release name]
Target Release Date: [Date]
Total Available Effort: [X person-weeks or story points]
Participants: [Names and roles]
Date: [Date]
Allocation Targets
| Category | Target % | Allocated Effort | Actual Effort |
|---|---|---|---|
| Must Have | 60% | [X person-weeks] | [Calc after filling] |
| Should Have | 20% | [X person-weeks] | [Calc after filling] |
| Could Have | 20% | [X person-weeks] | [Calc after filling] |
| Won't Have | 0% | 0 | 0 |
Must Have
Items the release cannot ship without. If any of these are missing, the release is a failure.
| # | Item | Effort | Rationale | Stakeholder | Status |
|---|---|---|---|---|---|
| M1 | [Requirement] | [Effort] | [Why this is essential] | [Who requested] | [Not Started / In Progress / Done] |
| M2 | [Requirement] | [Effort] | [Why this is essential] | [Who requested] | [Status] |
| M3 | [Requirement] | [Effort] | [Why this is essential] | [Who requested] | [Status] |
| M4 | [Requirement] | [Effort] | [Why this is essential] | [Who requested] | [Status] |
Should Have
Important items that add significant value but are not blockers to a viable release.
| # | Item | Effort | Rationale | Stakeholder | Status |
|---|---|---|---|---|---|
| S1 | [Requirement] | [Effort] | [Why this matters] | [Who requested] | [Status] |
| S2 | [Requirement] | [Effort] | [Why this matters] | [Who requested] | [Status] |
| S3 | [Requirement] | [Effort] | [Why this matters] | [Who requested] | [Status] |
Could Have
Nice-to-have items. First to be cut if the team runs out of time or capacity.
| # | Item | Effort | Rationale | Stakeholder | Status |
|---|---|---|---|---|---|
| C1 | [Requirement] | [Effort] | [Why it is nice to have] | [Who requested] | [Status] |
| C2 | [Requirement] | [Effort] | [Why it is nice to have] | [Who requested] | [Status] |
| C3 | [Requirement] | [Effort] | [Why it is nice to have] | [Who requested] | [Status] |
Won't Have (This Time)
Explicitly out of scope. May be revisited in a future release.
| # | Item | Effort | Rationale for Exclusion | Revisit In |
|---|---|---|---|---|
| W1 | [Requirement] | [Effort] | [Why it is excluded] | [Next quarter / V2 / TBD] |
| W2 | [Requirement] | [Effort] | [Why it is excluded] | [Revisit timeline] |
| W3 | [Requirement] | [Effort] | [Why it is excluded] | [Revisit timeline] |
Filled Example: FitTrack Mobile App MVP
Project: FitTrack MVP Launch (iOS)
Target Release Date: May 15, 2026
Total Available Effort: 24 person-weeks (3 engineers x 8 weeks)
Participants: Dana (PM), Leo (Eng Lead), Mia (Design), Chris (Founder)
Date: March 10, 2026
FitTrack is a fitness tracking app for casual gym-goers. The team needs to ship an MVP on the App Store by mid-May to hit a marketing window around summer fitness season. They have 20 candidate features from discovery interviews and competitor research.
Allocation Targets (Filled)
| Category | Target % | Allocated Effort | Actual Effort |
|---|---|---|---|
| Must Have | 60% | 14.4 person-weeks | 14 person-weeks |
| Should Have | 20% | 4.8 person-weeks | 5 person-weeks |
| Could Have | 20% | 4.8 person-weeks | 5 person-weeks |
| Won't Have | 0% | 0 | 0 |
Must Have (Filled)
| # | Item | Effort | Rationale | Stakeholder | Status |
|---|---|---|---|---|---|
| M1 | User registration (email + Apple Sign-In) | 2 pw | Cannot use the app without an account. Apple requires Apple Sign-In for App Store approval. | Leo (Eng) | Not Started |
| M2 | Workout logging (sets, reps, weight) | 4 pw | Core value prop. Users told us in 12/15 interviews that manual workout logging is the baseline expectation. | Dana (PM) | Not Started |
| M3 | Exercise library (200+ exercises with muscle group tags) | 3 pw | Without a pre-built library, users have to type exercise names manually. Competitors all include this. | Mia (Design) | Not Started |
| M4 | Workout history (calendar view, past workouts) | 3 pw | #2 requested feature in interviews. Users need to see progress over time. | Dana (PM) | Not Started |
| M5 | Basic onboarding flow (3 screens, goal selection) | 2 pw | App Store conversion data shows apps without onboarding have 40% lower Day-1 retention. | Chris (Founder) | Not Started |
Must Have total: 14 person-weeks (58% of capacity)
Should Have (Filled)
| # | Item | Effort | Rationale | Stakeholder | Status |
|---|---|---|---|---|---|
| S1 | Rest timer between sets (configurable) | 1.5 pw | 8/15 interviewees use a separate timer app during workouts. Building it in reduces friction. | Mia (Design) | Not Started |
| S2 | Personal records tracking (auto-detected) | 2 pw | Strong retention signal. Users who see PRs logged 3x more sessions in competitor data. | Dana (PM) | Not Started |
| S3 | Push notification reminders (workout days) | 1.5 pw | Retention lever. But the app works fine without it for MVP. | Chris (Founder) | Not Started |
Should Have total: 5 person-weeks (21% of capacity)
Could Have (Filled)
| # | Item | Effort | Rationale | Stakeholder | Status |
|---|---|---|---|---|---|
| C1 | Dark mode | 1 pw | Popular request but purely cosmetic. Easy to add post-launch. | Mia (Design) | Not Started |
| C2 | Export workout data to CSV | 1 pw | Power user feature. Only 2/15 interviewees mentioned it. | Leo (Eng) | Not Started |
| C3 | Body weight tracking with chart | 2 pw | Adjacent use case. Not core to workout logging. | Dana (PM) | Not Started |
| C4 | Custom exercise creation | 1 pw | Useful for advanced users. The 200-exercise library covers 95% of cases for MVP. | Leo (Eng) | Not Started |
Could Have total: 5 person-weeks (21% of capacity)
Won't Have This Time (Filled)
| # | Item | Effort | Rationale for Exclusion | Revisit In |
|---|---|---|---|---|
| W1 | Social features (follow friends, share workouts) | 8 pw | Too expensive for MVP. No evidence yet that social drives retention for this audience. | V2 (Q3 2026) |
| W2 | AI workout recommendations | 6 pw | Requires 3+ months of user data to train. Ship the basic logger first and collect data. | V3 (Q4 2026) |
| W3 | Apple Watch companion app | 4 pw | Significant engineering effort. Only 20% of target users own an Apple Watch. | V2 (Q3 2026) |
| W4 | Integration with MyFitnessPal / Apple Health | 3 pw | API integrations add complexity and testing burden. Focus on core experience first. | V2 (Q3 2026) |
| W5 | In-app subscription / paywall | 2 pw | MVP is free. Monetization starts after product-market fit is validated. | V2 (Q3 2026) |
Analysis
The Must Haves consume 58% of capacity, right within the 60% target. The team has 10 person-weeks left for Should and Could Haves.
All three Should Haves fit (5 person-weeks). The rest timer and PR tracking are the highest-impact retention features that do not require the core MVP scope to change. Push notifications are borderline but the team includes them because the implementation builds on existing infrastructure.
Could Haves total 5 person-weeks but will only ship if Should Haves come in under estimate. The team agrees that dark mode and CSV export are the most likely candidates since they are each about 1 person-week.
The Won't Have list is critical for managing Chris (the founder), who initially wanted social features in the MVP. By explicitly listing social features in Won't Have with a clear rationale ("no evidence that social drives retention") and a revisit date (Q3), the team avoids a scope creep battle later.
Key Takeaways
- MoSCoW is best for fixed-deadline, scope-negotiation situations where you need a clear line between "in" and "out"
- Must Haves should consume roughly 60% of capacity. If they exceed 80%, your scope is too ambitious for the timeline
- The "Won't Have" column is the most important. Making exclusions explicit and visible prevents scope creep and gives stakeholders a clear revisit timeline
- Always record the rationale for each placement. Stakeholders will challenge your categories. Written reasoning makes those conversations faster
- MoSCoW works at every scale: MVPs, quarterly releases, sprint commitments, and contract deliverables
- For features that are hard to categorize, try asking: "If we shipped tomorrow without this, would customers still get value?" If yes, it is not a Must Have. You can also run the items through the RICE Calculator to get a numeric tiebreaker
About This Template
Created by: Tim Adair
Last Updated: 2/19/2026
Version: 1.0.0
License: Free for personal and commercial use