## Intro MoSCoW prioritization is a lightweight decision framework that classifies work into four categories: Must Have, Should Have, Could Have, and Won't Have This Time. For CTOs, CIOs, product leaders, and engineering managers, it solves a daily problem: far more valuable ideas than capacity to deliver. Used with clear rules and a fixed timebox, MoSCoW reduces conflict, exposes trade-offs, and makes delivery more predictable. Practical takeaway: define strict category rules, cap Musts within capacity, force-rank within each category, and publish one clear plan for the timebox. Use evidence, not volume, to set priority. ## When to use MoSCoW (and when not) Use MoSCoW when: - You plan a fixed timebox (e.g., 2–8 weeks) and must hit a few non-negotiable outcomes. - Backlog sources are mixed (features, incidents, tech debt, compliance, research) and you need a shared language. - Dependencies and risks matter as much as new feature value. Avoid or complement MoSCoW when: - You need fine-grained economic ranking across many options (consider RICE, WSJF, or cost of delay). - There is no fixed capacity or timebox. Prioritizing into a vacuum invites Must inflation. - Discovery is still underway and options are unclear. First narrow with problem framing and discovery spikes. Prerequisites: - A timebox and capacity assumptions agreed in advance. - Candidate items with a problem statement, owner, rough size, and minimal evidence. - A single decision owner empowered to break ties after hearing stakeholders. ## Strict category definitions and validation rules These definitions are designed to withstand pushback and prevent inflation. ### Must Have Definition: Non-negotiable for this timebox. If any Must is missing, the release fails its core objective or violates a hard constraint. Validation rules: - Consequence test: Without it, do we breach an SLA, regulatory/contractual requirement, security posture, or a publicized commitment tied to an OKR (Objectives and Key Results)? If not, it is not a Must. - Capacity cap: Sum of Must estimates fits within 50–60% of total timebox capacity to leave room for uncertainty, risk, and interrupts. - Acceptance criteria: Written and testable before work starts. - Dependencies: All prerequisite work for Musts is included in Must or already complete. ### Should Have Definition: High-value for this timebox with a viable workaround if deferred. Missing it does not cause failure of the release objective. Validation rules: - Material impact on near-term revenue, retention, risk reduction, or customer experience. - Acceptance criteria defined before start. - Force-ranked against all other Shoulds. ### Could Have Definition: Useful enhancements, learning opportunities, or cost improvements that are safe to drop if pressure rises. Validation rules: - Clear benefit exists, but no immediate risk or commitment depends on it. - Minimal acceptance notes are enough; discovery can continue opportunistically. - First candidates to trade out if Musts threaten the plan. ### Won't Have This Time Definition: Explicitly out of scope for this timebox with a documented revisit date or trigger. Validation rules: - Missing critical evidence, unclear ownership, or size too uncertain for this window. - Not tied to this timebox goals. - Recorded in the backlog with rationale to prevent later relitigation. ## Guardrails that prevent Must inflation - Fix the timebox and capacity first. Example: 6 weeks, 30 engineer-weeks after support, PTO, and ceremonies. - Cap Musts at 50–60% of capacity. Treat this as a hard budget. - Include dependency and risk obligations in Must if they are prerequisites for Must work. - Apply the consequence test: if we drop it, what specifically breaks and when? If the answer is inconvenience or reputational discomfort, it is a Should. - Force-rank within each category to simplify trade-offs under stress. - Never extend the timebox to “save” Musts; drop Coulds first, then lower-ranked Shoulds. ## Facilitation, decision rights, and evidence A 90-minute MoSCoW workshop is often enough to align a cross-functional group. Preparation (48–72 hours before): - Publish inputs: list of candidates (problem statement, owner, estimated size, dependencies, minimal evidence). - Confirm timebox capacity and Must cap. State known constraints and interrupts. - Assign a single decision owner (e.g., Head of Product or CTO). Clarify who advises (engineering, design, security, finance, operations). During the session: - Categorize first, then rank within categories. Do not debate estimates in detail; capture ranges or T-shirt sizes. - Apply validation rules and the consequence test out loud. Require acceptance criteria for Must/Should before commit. - Record disagreements, the evidence cited, and the final decision owner call if consensus fails. Evidence requirements (right-sized): - Customer: usage, adoption, churn drivers, support tickets. - Business: revenue at risk, margin impact, contract clauses, SLAs. - Technology: reliability metrics, security findings, performance baselines, dependencies, capacity constraints. - Confidence: note unknowns and targeted discovery to reduce risk. Common anti-patterns to avoid: - Category creep: expanding Musts until capacity breaks. - Hidden work: untracked dependencies or risk remediation not included in Must. - Tie-heavy lists: lack of force-ranking causes churn during execution. - Unbounded discovery: starting Must work without acceptance criteria or a clear definition of done. - Endless relitigation: failing to publish decisions with rationale and revisit dates. ## A reusable prioritization table (template) Use this table structure in your tracker to keep decisions auditable.
ItemProblem statementSize (weeks)DependenciesEvidence summaryCategoryRank in cat.OwnerAcceptance criteriaValidation notes
Example: SSO reliability fixLogin failures spike at 0.8% breaching SLA6DB failover updateSLA breach risk, incident trendMust1Eng Mgr, AuthError rate <0.2%, failover test passConsequence test met
## Realistic release example (hypothetical) Context: A 35-person startup with product engineering, a platform team, and data. Timebox: 6 weeks. Effective capacity: 30 engineer-weeks after support and leave. Must cap: 18 weeks (60%). Key goals: protect reliability, fulfill one enterprise commitment, and reduce unit cloud cost. Candidate items (rough sizes): - A. SSO reliability fix (6) — SLA breach risk; depends on DB failover update. - B. Enterprise reporting export (5) — committed in signed SOW; design approved. - C. Reduce hot-path query costs (3) — expected 10–15% infra savings. - D. New onboarding tour (3) — improves activation; marketing push planned. - E. Data pipeline hardening (4) — intermittent failures, on-call fatigue. - F. Feature flag refactor (2) — tech debt slowing release toggles. - G. Mobile push improvements (3) — could lift engagement; no external commitment. - H. Security dependency upgrades (2) — medium CVEs; no known exploits. Stakeholder disagreements (illustrative): - Sales argues D (onboarding tour) is critical for the marketing launch. - Finance pushes C (cost savings) higher due to rising spend. - SRE insists E (pipeline hardening) is overdue risk work causing pages. Categorization using validation rules: - Must (total 17): A SSO reliability fix (6), B Enterprise reporting export (5), E Data pipeline hardening (4), H Security upgrades (2). Rationale: A breaches SLA; B is contractual; E reduces operational risk and on-call burn tied to reliability objectives; H addresses CVEs with compliance implications. Dependencies: DB failover update is included within A’s size. - Should (total 5): C Reduce query costs (3), D Onboarding tour (2 of 3). Rationale: Near-term business value; workarounds exist (manual export for onboarding analytics). Agreement to trim D’s initial scope to 2 weeks (tour for top 3 flows only) with acceptance criteria. - Could (total 5): F Feature flag refactor (2), G Mobile push improvements (3). Useful but safe to drop under pressure. - Won’t Have This Time: Any net-new analytics refresh ideas lacking acceptance criteria and owners. Force-ranking within categories: - Must: 1) A, 2) B, 3) E, 4) H. - Should: 1) C, 2) D. - Could: 1) F, 2) G. Execution plan: - Owners assigned for each item; acceptance criteria finalized for Must/Should. - Weekly inspection covering delivery-to-plan, blocked items, and risk changes. - Guardrail: If Must schedule threatened, drop Coulds first (F, then G), then the lowest-ranked Should (D before C), without extending timebox. What changes when capacity drops? Mid-cycle, two engineers are pulled into incident response. Capacity falls from 30 to 24 engineer-weeks. Re-apply rules: - Recompute Must cap: 60% of 24 = 14.4; round down to 14 weeks. - Musts currently total 17 weeks, so adjust: Keep A (6) and B (5) as non-negotiable; choose between E (4) and H (2) using consequence test. E wins due to ongoing instability; H moves to Should top spot; new Must total = 15, still high. - Trim E scope by 1 week (e.g., limit to the flakiest pipeline stage) to bring Musts to 14. - Should now becomes: 1) H (2), 2) C (3), 3) D (2). Total Should=7. If any Must overruns, drop Shoulds starting from the bottom (D, then C, then H) while preserving security risk windows. Published decision memo: - State the new capacity, updated Must list, the trade-offs made, and the revisit date for H. ## How MoSCoW compares to other methods - RICE (Reach, Impact, Confidence, Effort): Produces a numeric score for demand-side bets. Great for growth teams and backlogs of features with measurable reach. Complement MoSCoW by using RICE to inform rank within Should/Could. - WSJF (Weighted Shortest Job First): Divides cost of delay by job size to maximize economic throughput. Powerful where you can credibly estimate delay costs. Use alongside MoSCoW when Sequencing within Should/Could needs a throughput lens. - Kano: Classifies features as must-be, performance, or delighters based on customer perception. Useful in discovery; less operational during release execution. Feed Kano insights into category choices. - Cost of Delay: Emphasizes time sensitivity of value or risk. Excellent for deciding drop/trade when capacity falls mid-cycle. - Simple stack ranking: Quick, but brittle when mixing constraints (compliance vs. experiments). MoSCoW adds clarity by separating must-not-fail items from discretionary ones. Rule of thumb: Use MoSCoW to set the line between non-negotiable and discretionary in a fixed timebox; use RICE/WSJF/Cost of Delay to rank within discretionary work. ## Metrics that keep the process honest Define and track a small set of metrics and label them clearly. - Leading metrics: plan stability (weekly delta in category membership), blocked days per Must item, decision latency (proposal to categorization). - Lagging metrics: percent of Must items delivered in the timebox, post-release incident rate, realized savings vs. plan. - Diagnostic metrics: rework rate (items rescoped/reopened), dependency lead time, item age in progress. - Guardrail metrics: on-call burn (pages per week), security exposure window (days to patch for CVEs), capacity utilization vs. cap for Musts. - Vanity metrics to avoid: raw story counts, lines of code, or unqualified “velocity” without context. Target a lightweight weekly review: highlight exceptions, proposed swaps within categories, and any breach of the Must cap. ## Step-by-step facilitation checklist - Readiness - Timebox, capacity, and constraints documented. - Category definitions agreed and published with examples. - Decision owner named; escalation path clear. - Each item has a problem statement, owner, rough size, and minimal evidence. - Prioritization discipline - Musts <= 50–60% capacity; dependencies included. - Force-ranked within each category. - Acceptance criteria written for Must and Should. - Explicit Won't Have list with revisit dates. - Communication - One-page summary: goals, definitions, category lists, owners. - State what dropped and why to avoid relitigation. - Execution - Weekly inspection: progress, risks, swaps by rank only. - If Musts slip: drop Coulds first, then lowest-ranked Shoulds; never extend the timebox. ## Limitations and practical tips - Estimates are uncertain. Protect slack via the Must cap and clear acceptance criteria. - Not all risks are quantifiable. Use consequence tests and guardrail metrics. - Culture matters. Publish decisions with names, evidence, and revisit dates to build trust. - Start small. Pilot on one team for one timebox, inspect results, then refine rules. ## Conclusion MoSCoW works when it is concrete, constrained, and auditable. Define strict category rules, cap Musts, force-rank, and publish decisions with evidence and owners. Pair MoSCoW with RICE, WSJF, and cost of delay to rank discretionary work. The result is fewer surprises, clearer expectations, and a higher hit rate on the commitments that matter most.