Learning guide and study notes
What matters most within this timebox? Use it when demand exceeds capacity.
Prioritization thinking forces explicit ranking within a fixed time and capacity box—separating non-negotiable safety and viability Must-haves from worthwhile extras, and publishing what will not be done this cycle.
MoSCoW separates Must, Should, Could and Won’t have this time. It makes exclusions visible, not permanent judgments about importance.
Work through these steps in order, applying the tools above. Write down the answer to each step before moving on.
State the minimum viable outcome and available capacity before ranking items. [1] Source: Agile Business Consortium — MoSCoW Prioritization (opens in a new tab)
Ask whether failure to deliver an item makes the result unusable or unsafe; otherwise assess Should, Could or Won’t this time. [1] Source: Agile Business Consortium — MoSCoW Prioritization (opens in a new tab)
Publish the Won’t list and revisit scope when conditions change. [1] Source: Agile Business Consortium — MoSCoW Prioritization (opens in a new tab)
For one deadline, sort ten requests into Must, Should, Could and Won’t; explain one difficult exclusion.
Situation: A service migration has a fixed launch date.
How to apply: Treat access control and tested rollback as Musts; postpone dashboard polish and later-region expansion.
Outcome: Publish the boundary so safety work is not displaced by visible extras.
Situation: A team has 12 sprint requests totaling 180% of available engineering capacity before quarter end.
How to apply: Cap Must-have effort below 60% of capacity, test each item with “Can we safely go live without this?”, and move four UI enhancements to the Won’t-this-time list.
Outcome: Deliver all critical security and core workflow commitments on time without burning out the on-call team.
Situation: A storage degradation impacts checkout, internal analytics, and staging environments simultaneously.
How to apply: Rank recovery strictly by customer and safety impact: restore checkout writes first, pause batch analytics second, and defer staging repairs.
Outcome: Protect core revenue and user trust within minutes instead of splitting responder attention across three fronts.
Illustrative examples showing how the lens changes decisions; not measured outcomes.
Watch out: If nearly everything is a Must, the categories no longer prioritize anything.
Combine this lens with others rather than relying on it alone. Browse all thinkings
Priority is a choice under limited capacity; make the criteria and what will wait explicit.
Use a problem of your own. Write a short answer to each prompt, then return after trying the method.
Answer from memory before opening the suggested answer.
No. Safety requirements, dependencies, capacity, and weak scoring assumptions can override the ranking. Scores support judgment rather than replace it.
It makes the capacity trade-off explicit and prevents everything from remaining nominally urgent. Deferred items need review conditions too.
These sources support the method; the examples and exercises are original teaching illustrations.