Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Acceptance Criteria

Pattern

A reusable solution you can apply to your work.

Also known as: Definition of Done, Exit Criteria, Completion Conditions

Understand This First

  • Requirement – criteria verify that requirements are met.
  • Constraint – some criteria encode constraint compliance.

Context

This is a strategic pattern. You have an Application with requirements and constraints. Someone — a developer, a team, or an AI agent — is about to start working on a task. Before they begin, you need to answer the question: How will we know when this is done?

In agentic coding, acceptance criteria matter more than in traditional development. A human developer might notice that a feature “works but doesn’t feel right” and keep polishing. An AI agent stops the moment it believes the task is complete. The finish line you define is the finish line the agent crosses, no more, no less.

Problem

Without explicit completion conditions, “done” becomes a matter of opinion. Tasks drag on because nobody agrees when they’re finished. Or worse, tasks get declared complete when they only work on the surface: passing the happy path but failing at edges, missing error handling, or ignoring non-functional requirements.

How do you define “done” in a way that is specific enough to verify and complete enough to catch real problems?

Forces

  • You want criteria to be thorough, but overly detailed criteria are expensive to write and brittle to maintain.
  • Criteria should be objective and testable, but some qualities (usability, code clarity) resist simple true/false checks.
  • In agentic workflows, the agent optimizes for exactly the criteria you state, nothing more and nothing less.
  • Unstated criteria are unmet criteria.

Solution

For each task or requirement, write a short list of concrete, verifiable conditions that must all be true for the work to be accepted. Good acceptance criteria share a few properties:

Specific. “The search feature works” isn’t a criterion. “Searching for a keyword returns matching tasks sorted by most recent, within 200ms” is.

Testable. Each criterion should suggest a test: something you can run, click through, or inspect to confirm it.

Complete enough. Cover the happy path, important edge cases, and relevant non-functional qualities. You don’t need to anticipate every scenario, but you should cover the ones that matter.

Independent of implementation. Criteria describe what must be true, not how to achieve it. “Uses a binary search” is an implementation detail. “Returns results within 200ms for collections up to 10,000 items” is a criterion.

When directing an AI agent, include acceptance criteria in your prompt or task description. The agent will use them to decide when to stop working and what to test.

How It Plays Out

A developer asks an agent: “Add user authentication to the app.” The agent adds a login form and a password check. There’s no logout, no session expiry, no password hashing, and no error message for wrong credentials. The agent stopped because the task, as stated, was complete: users can authenticate.

Now consider: “Add user authentication. Acceptance criteria: (1) Users can log in with email and password. (2) Passwords are hashed with bcrypt before storage. (3) Failed login shows a specific error message. (4) Sessions expire after 24 hours of inactivity. (5) Users can log out, which destroys the session.” The agent now has a concrete finish line that covers security, usability, and session management.

Tip

When writing acceptance criteria for an AI agent, include at least one criterion about error handling and one about edge cases. Agents tend to optimize for the happy path unless you explicitly ask them to handle failure modes.

Example Prompt

“Add user authentication. Acceptance criteria: (1) users log in with email and password, (2) passwords are hashed with bcrypt, (3) failed login shows a clear error, (4) sessions expire after 24 hours, (5) users can log out and destroy their session.”

Consequences

Clear acceptance criteria reduce ambiguity, prevent premature completion, and give you a concrete basis for testing and review. They make code review faster because the reviewer can check criteria rather than guessing at intent.

The cost is effort up front. Writing good criteria requires thinking through the task before starting it, which is exactly the point. You’ll also find that criteria evolve as you learn; that’s normal. Update them as your understanding deepens, but always have something written before work begins.

In agentic workflows, acceptance criteria become a form of communication with the agent. They’re the most reliable way to ensure the agent’s output matches your actual intent.

  • Depends on: Requirement — criteria verify that requirements are met.
  • Depends on: Constraint — some criteria encode constraint compliance.
  • Uses: Tradeoff — writing criteria forces you to decide which qualities matter enough to verify.
  • Contrasts with: Judgment — criteria handle the verifiable; judgment handles the rest.