The Four Categories of Acceptance Criteria: Reducing Uncertainty Before Design Begins

After spending more than a decade working across different flavours of agile teams, one pattern has remained consistent.

Teams struggle not because they lack skill or intent,
but because acceptance criteria are either vague, overloaded, or incomplete.

When acceptance criteria are weak, design becomes speculative, implementation becomes reactive, and uncertainty leaks into every downstream decision.

Acceptance Criteria as a Thinking Tool

Acceptance criteria are often treated as a checklist — something to validate after implementation.

That framing is backwards.

At scale, acceptance criteria are a thinking tool.
They exist to make intent explicit before design and delivery begin.

The fastest way to improve acceptance criteria is not to add more detail, but to classify intent clearly.

Why Classification Matters

One of the most effective ways to define anything complex is to first narrow the problem space.

Once narrowed, the next step is classification.

Classification:

• removes ambiguity
• exposes constraints
• creates shared understanding
• and enables meaningful design conversations

Without classification, acceptance criteria become a flat list — and flat lists hide uncertainty.

The Four Categories of Acceptance Criteria

Over time, I’ve found it useful to classify acceptance criteria into four distinct categories.

Each category answers a different question about the system.

1. Musts — Non-Negotiable Requirements

Musts define what the system has to do in order to be considered correct.

These are the core requirements:

• without which the solution has no value
• and failure is not acceptable

Musts establish the minimum viable correctness of the system.

2. Ought Nots — Explicit Constraints

Ought nots define what the system must not be or do.

These constraints often get overlooked, yet they are critical.

They may include:

• security boundaries
• compliance limitations
• performance ceilings
• architectural guardrails

Making constraints explicit early prevents expensive rework later.

3. Wants — Value Enhancers

Wants describe behaviors or features that enhance the value of the solution but are not mandatory for correctness.

These are important, but optional:

• they improve usability
• increase adoption
• or strengthen experience

Separating wants from musts enables better prioritization and sequencing.

4. Don’t Wants — Value Erosion Signals

Don’t wants capture behaviors that reduce the value of the solution.

They represent:

• negative user experiences
• operational friction
• or unintended side effects

Explicitly calling these out protects the solution from subtle degradation over time.

Why This Classification Works

When acceptance criteria are structured this way, several things happen naturally:

• Teams gain clarity on intent
• Design discussions become focused
• Trade-offs become visible
• Assumptions surface early

Most importantly, this structure reduces technical uncertainty before design begins.

That is where acceptance criteria deliver their real value.

From Understanding to Synthesis

Once musts, ought nots, wants, and don’t wants are clear, teams can move confidently into design.

At this point:

• the problem is well understood
• constraints are explicit
• and synthesis of design concepts can begin with confidence

Acceptance criteria stop being documentation and start becoming an enabler of good engineering.

Closing Thought

Strong acceptance criteria are not about control.

They are about clarity.

And clarity is what allows teams to design, build, and evolve systems with intent rather than guesswork.