Buffered MoSCoW

Buffered MoSCoW fills a fixed time box with features in the customer’s order of preference, and lets the uncertainty of the team’s estimates, not a fixed percentage, decide how many features become Must, Should or Could Haves [1].

1. Two MoSCoWs

Clegg and Barker coined the categories in 1994 with no cap [2], [3]. DSDM added an effort ceiling: Musts at “no more than 60%”, Coulds “around 20%”, and no figure for Shoulds [4]. Miranda keeps the ranking but changes what the categories mean:

Category	DSDM: what if it is missing?	Buffered MoSCoW: how likely is it?
Must	the “Minimum Usable SubseT” the project guarantees	deliverable “short of a calamity”
Should	important but not vital	“a fair chance of being delivered”
Could	“the main pool of contingency”	only “if everything went extraordinarily well”
Won’t	agreed not to be delivered this time	no budget left at its safe estimate

The customer owns the order; the estimates own where the line falls.

2. How it works

Each feature gets two estimates: a normal one with a fair chance of being enough, and a safe one that is enough except in a few really bad cases. In five steps [1]:

1. Musts. Take features in the customer’s order, with their prerequisites, at their safe estimates until the development budget is used up. A feature that does not fit is passed over.
2. The Must buffer. Re-plan the Musts at their normal estimates. The time freed is the buffer that protects them.
3. Shoulds. Choose them in the customer’s order, at their safe estimates, inside the Must buffer. Re-plan them at normal; the time freed is the Should buffer.
4. Coulds. The same rule, inside the Should buffer.
5. Won’ts. Whatever fits nowhere at its safe estimate.

Miranda 2011, Fig. 1.

Each category uses “the size of the buffer protecting the previous category as the initial budget for the current one”. Miranda defines the Must buffer as the Musts’ safe total minus their normal total; his worked example passes on all the budget left once the Musts are at normal. The two agree when the safe fill uses the whole budget.

Each step roughly halves the odds, so a Must is about twice as likely to be delivered as a Should and four times as likely as a Could. Miranda gives no fixed percentages.

3. A worked release

Example. Quill, a fictional word processor, has a 180-hour time box: 60 hours of overhead, 120 for development. The customer ranks twelve features, starting with open and save, character formatting, spell checker and track changes.

Category	Quill features	Safe (h)	Normal (h)	Budget (h)
Must	open and save, character formatting, font engine, spell checker, dictionary loader, text tokeniser, page layout	109	71	120
Should	track changes	40	20	49
Could	word count	18	10	29
Won’t	table of contents, mail merge, paragraph styles	—	—	—

The numbers and order are Miranda’s features A–L (Tables 1–4) [1]; the names are ours.

Track changes, ranked fourth, is not a Must: once the spell checker has brought in its dictionary loader and tokeniser, its 40-hour safe estimate no longer fits. The Musts at normal take 71 of 120 hours, or 59%. The estimates reproduce DSDM’s 60% rule of thumb instead of assuming it.

If the spell checker then takes 40 hours instead of 20, the Must buffer absorbs it. Track changes keeps a fair chance, word count’s chance becomes slim, and the release date does not move.

4. When to use it, and when not

Use it, per project or increment, when the date is fixed, the customer can rank, and the team can give two honest estimates.

It protects against overruns, not scope changes. A new requirement enters at the expense of a planned one, or by changing the time box [1]. For a stated probability rather than “short of a calamity”, use SPID, which plans at about 95% confidence [5].

The main pitfall is correlation. An immature open-source library slows the testing of every feature that uses it, so features overrun together and the buffer is smaller than it looks [3].

How solid is this?

• Where it comes from. Miranda 2011 is a five-page essay with an invented example; the double and quadruple likelihoods are argued, not measured.
• What the simulation shows. Miranda 2022 simulated DSDM’s 60/20/20 with single-point estimates, not this method. At 60% Musts and independent estimates, all Musts survived overruns of up to 100% with 98.9–100% probability; correlated, low-confidence estimates gave 74%, and 70% Musts gave 34% [3]. These are model outputs, not project data.
• What is ours. The 59% echo is our reading, not Miranda’s claim. Rubin’s “closer to 60% to 70%” is practitioner experience [6].

---

Acknowledgments

This page adapts material from lectures by Eduardo Miranda [7] on software project management.

References

1. E. Miranda,
   “Time boxing planning: buffered moscow rules,” ACM SIGSOFT Software Engineering Notes, vol. 36, no. 6, pp. 1–5, Nov. 2011, doi: 10.1145/2047414.2047428.
2. D. Clegg and R. Barker,
   Case Method Fast-Track: A Rad Approach. Addison-Wesley Longman Publishing Co., Inc., 1994.
3. E. Miranda,
   “Moscow Rules: A Quantitative Exposé,” in Agile Processes in Software Engineering and Extreme Programming (XP 2022), in Lecture Notes in Business Information Processing. Springer, 2022, pp. 19–34. doi: 10.1007/978-3-031-08169-9_2.
4. DSDM Consortium,
   The DSDM Agile Project Framework. Dynamic Systems Development Method Limited, 2014. [Online]. Available: https://www.agilebusiness.org/wp-content/uploads/2026/05/DSDM-Agile-Project-Framework-Handbook.pdf
5. E. Miranda,
   “Planning and executing time-bound projects,” Computer, vol. 35, no. 3, pp. 73–79, Mar. 2002, doi: 10.1109/2.989933.
6. K. S. Rubin,
   Essential Scrum: A Practical Guide to the Most Popular Agile Process. in Addison-Wesley Signature Series (Cohn). Addison-Wesley Professional, 2012. [Online]. Available: https://innolution.com/essential-scrum
7. E. Miranda,
   “Managing Software Development.” 2014.

---

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.