MoSCoW prioritisation tool
Sort features into must, should, could and won't have for a first release.
FreeRuns in your browserNo signupUpdated 2026-11-05
The features below are an example for a booking app. Replace them with your own.
Features
Shares are of the effort in this release, so Won't have items are left out of the percentages.
Must have share of effort
55%
21 of 38 days in scope
Could have share of effort
26%
Your contingency if estimates slip
Must haves are within the 60% DSDM guideline
Must have · 21 days
The release fails or cannot go live without it.
- Sign-up and login5
- Book an appointment8
- Staff calendar view6
- Email confirmations2
Should have · 7 days
Important, but there is a workaround for now.
- Reschedule and cancel online4
- SMS reminders3
Could have · 10 days
Nice to have; first to drop if time runs short.
- Online payment at booking6
- Patient reviews4
Won't have this time · 35 days
Agreed as out of this release.
- Native mobile apps30
- Loyalty points5
# MoSCoW priorities for First release: online booking Effort in scope (must, should and could): 38 days. Must have: 55% · Should have: 18% · Could have: 26%. ## Must have (21 days) - Sign-up and login (5 days) - Book an appointment (8 days) - Staff calendar view (6 days) - Email confirmations (2 days) ## Should have (7 days) - Reschedule and cancel online (4 days) - SMS reminders (3 days) ## Could have (10 days) - Online payment at booking (6 days) - Patient reviews (4 days) ## Won't have this time (35 days) - Native mobile apps (30 days) - Loyalty points (5 days)
Paste the Markdown into a ticket, a README or a shared doc so everyone works from the same list.
About this tool
How it works and how to read the result.
Need this done for you?
Web app & SaaS development
SaaS products and web apps, from first version to scale.
See the serviceWhat it does
This MoSCoW prioritisation tool helps you agree what goes into a first release. List the features, put each one in must have, should have, could have or won't have this time, and give it an effort estimate in days, weeks or story points. The page groups the list into four columns, shows what share of the effort in the release each group takes, and checks the must-have share against the guideline in the DSDM framework. It also writes the result as a Markdown document you can copy or download. It runs in your browser.
How to use it
- Name the release and pick an effort unit.
- Edit the example features, or paste your own list into "Add features", one per line.
- Set each feature to Must, Should, Could or Won't, and give it an effort estimate.
- Watch the must-have share. If it is over 60%, move items down or split them.
- Copy or download the Markdown and share it with everyone who signs off the scope.
How to read the result
The example plans the first release of a clinic booking app, with effort in days. The must haves are sign-up and login (5), booking an appointment (8), a staff calendar view (6) and email confirmations (2), which is 21 days. Rescheduling online and SMS reminders are should haves at 7 days. Online payment and patient reviews are could haves at 10 days. Native mobile apps and loyalty points are agreed as won't have this time, and are left out of the percentages.
That gives 38 days in scope. Must haves are 21 ÷ 38 = 55%, should haves 18% and could haves 26%. The Agile Business Consortium's guide to MoSCoW recommends typically no more than 60% must-have effort and around 20% could-have effort, so this plan has room for estimates to slip.
Now move online payment to Must. Must haves become 27 ÷ 38 = 71% and the badge turns red. Either payment really is essential, in which case something else must come out, or it can wait for the second release while customers pay at the clinic. Making that trade-off in a planning meeting is much cheaper than discovering it in the last week of the build.
The won't-have column matters as much as the must-haves. Writing down what you are not building stops the same requests coming back every week, and gives you a ready list for the next release. When you have a scope you agree on, turn it into dates with the project timeline calculator or a rough budget with the app development cost calculator.
Once the must haves are agreed, our web app development service can build the first release.
Questions
Frequently asked.
What does MoSCoW stand for?
Must have, Should have, Could have and Won't have this time. The o's are only there to make it pronounceable. The method comes from DSDM, an agile project framework, and is used to agree what a release or timebox will and will not include before the work starts.
How do I decide if something is a must have?
Ask what happens if it is missing on launch day. If the release cannot go live, is illegal or unsafe, or does not solve the problem at all, it is a must. If there is a workaround, even a manual one, it is a should. Teams that call everything a must have usually have not asked this question.
Why does the must-have share of effort matter?
Estimates are rarely exact. If must haves take up all the time, any overrun means the release is late. Keeping must haves to a share of the effort leaves the should and could items as a buffer: when time runs short you drop a could, not the launch date.
More in Business & pricing
Related tools.
Your next move
Like what you see? Tell us about it.
A process that takes too long, a website that undersells you, or an idea ready to take shape. Tell us where you are and we will suggest a useful next step.
India · Working with clients worldwide