Could Filter¶

Prioritization rubric — instantiates Minimum Sufficient Solution

Sorts every proposed piece of scope into must / should / could / won't-now tiers so a team can defend a smaller release item by item.

Version: v1 · 2026-08-24 · History
Mechanism #: 5513
Type: Prioritization Rubric
Form family: Decision, Gate & Allocation
Solution family: Boundary & Scope Control
Problem family: Complexity, Entanglement & Change Burden
Problem subfamily: Unearned Scope & Accidental Complexity
Origin domain: Computer Science & Software Engineering
Also from: Innovation & Entrepreneurship, Organizational & Management Science
Instantiates: Minimum Sufficient Solution

The Must/Should/Could Filter is the graded sorting act: it takes every proposed piece of scope and assigns it to a tier — must have this time, should have if at all possible, could have if effort permits, or won't have this time — so a team can draw a defensible line under a smaller release. Its defining move, and the line that separates it from a static roster, is that it grades each item on its own, one at a time, against a shared bar, rather than declaring a finished list. The tiers are not decoration: the won't-now items carry a promise to be reconsidered, and the should/could ordering is itself the shape by which scope will grow. What comes out is not a document of the answer but a decision each proposal has passed through.

Example¶

A nonprofit is planning its annual fundraising gala with six weeks and a thin volunteer crew. The wishlist runs long: silent auction, live auction, a keynote speaker, a photo booth, a printed program, valet parking, a signature cocktail, a video montage, table centerpieces, a mobile bidding app. The team runs each item through the filter against one bar — does the evening fail its purpose without it? Ticketing, a working sound system, a payment method for donations, and enough seating are musts. A short program and the live auction are shoulds. The photo booth and signature cocktail are coulds, taken only if a volunteer has spare hours. Valet parking and the bidding app are won't-this-year, with a note to revisit if attendance crosses 300. The value is not the list; it is that every "can we add…?" now has a tier and a reason attached, and the won't items each carry an explicit revisit trigger rather than an argument.

How it works¶

Set one shared bar. Agree what "must" means — usually "the solution fails its core purpose without it" — before sorting, so tiering is not a popularity contest.
Grade each item, one at a time. Every proposal gets exactly one tier; the discipline is that must is scarce and defended, not handed out.
Order the middle tiers. Should above could gives the sequence in which deferred scope earns its way back.
Attach a revisit condition to the won'ts. Each dropped item names what evidence would move it up a tier next cycle, so deferral is a scheduled decision, not a quiet death.

Tuning parameters¶

Must-tier scarcity — how jealously the top tier is guarded. A narrow must forces a lean release; a generous one quietly restores the bloat the filter exists to prevent.
Tier count — classic four tiers, or a coarser must/not-now cut. More tiers order growth more finely but slow the sort and invite haggling.
Sorting quorum — who assigns tiers, from one owner to a stakeholder vote. Broader input buys legitimacy at the cost of speed and inflated musts.
Revisit horizon — how soon won't-now items are reconsidered. A near horizon keeps momentum; a distant one lets deferrals settle and reduces churn.

When it helps, and when it misleads¶

Its strength is that it makes a smaller release defensible item by item: each cut has a tier, a reason, and a path back, which is exactly what lets a team tell a stakeholder "not now" without pretending the request has no value. The method is old and battle-tested — the MoSCoW prioritization popularized in DSDM is the canonical form.^[n1] Its failure mode is tier inflation: when everything migrates to must, the filter has sorted nothing and simply blessed the original scope. The classic misuse is treating the tiering as a one-time ritual whose won't items are never actually revisited, so "deferred" becomes a polite synonym for "denied." The guarding discipline is to cap or defend the must-tier and to honor the revisit horizon on the drops.

How it implements the components¶

nonessential_feature_filter — the graded four-tier sort is the filter, applied to each proposed part on its own against a shared "fails without it" bar.
review_trigger — each won't-now item carries the condition that would reopen it, making deferral an accountable, scheduled decision.
expansion_path — the should-then-could ordering is the sequence by which deferred scope is allowed back in as capacity appears.

It grades and orders proposals, but it does not maintain the durable deferred_enhancement_backlog roster or trace each item to a stakeholder_need_trace — those artifacts belong to Essential Feature Set, its nearest twin — and it never names the core_requirement that the bar is derived from; it consumes that.

Instantiates: Minimum Sufficient Solution — the filter is the per-item sorting act that produces a defensible minimum.
Sibling mechanisms: Essential Feature Set · Lean Policy Design · Minimum Viable Documentation · MVP-like Scoping · Pilotable Solution · Simple Intervention Package · Minimum Viable Process

Editorial Notes¶

Form Classification¶

Form family: Decision, Gate & Allocation

Rationale: Must/Should/Could Filter operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it sorts every proposed piece of scope into must / should / could / won't-now tiers so a team can defend a smaller release item by item.

Independent corroboration: The frozen evidence defines Must/Should/Could Filter as 'Sorts every proposed piece of scope into must / should / could / won't-now tiers so a team can defend a smaller release item by item', so its operative form is Decision, Gate & Allocation.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution¶

Primary origin: Computer Science & Software Engineering

Origin pattern: Single lineage

Present-day reach: Multi-domain

Rationale: The MoSCoW must-should-could-won't prioritization scheme emerged in software requirements and agile delivery practice.

Related originating lineages:

Innovation & Entrepreneurship — Lean product scoping made it a common minimum-release tool.
Organizational & Management Science — Project governance generalized it to scope and resource negotiation.