Acceptance Criteria Checklist¶

Acceptance artifact — instantiates Sufficiency-Bounded Work Containment

Pins a single deliverable to a short list of pass/fail conditions written before work starts, so "finished" means every box is ticked and nothing beyond them is owed.

An Acceptance Criteria Checklist pins one specific deliverable to a short, explicit list of conditions it must satisfy to be accepted — each phrased as a pass/fail check, all agreed before the work begins. Its defining move is that the list is bespoke to this one item and closed: it states what this deliverable must do and, by everything it omits, what this deliverable does not owe. That closure is the fence. Where a Definition of Done is one reusable bar every item in the shop must clear, acceptance criteria are unique to a single item and drawn around it — so "finished" becomes decidable by inspection rather than by feel, and the ticked list doubles as its own receipt that the item was accepted on the terms agreed, not on whatever polish occurred to someone mid-build.

Example¶

A freelance designer takes a logo commission. Before opening the design tool, she and the client agree the acceptance criteria: three concept directions to choose from; the chosen mark delivered as vector plus PNG at four sizes; one-colour and reversed variants; and a two-round revision limit. That short list is the whole fence. Midway, the client mentions a matching social banner and a business-card layout would be "great to have." Because those are not on the list, they surface as visibly new work rather than an implied part of "the logo" — a separate quote, not silent expansion. When the files and variants are delivered and each line is ticked off, the job is done: the checked list is the record both sides accept, and the designer stops rather than gold-plating a fifth concept nobody asked for.

How it works¶

Agreed before work starts, so the criteria constrain the work instead of rationalising it after the fact.
Each criterion is a pass/fail check, not a direction — "vector plus PNG at four sizes," not "high-quality files." Checkability is what makes closure decidable.
The list is closed: anything not on it is out of scope by default, which turns would-be scope growth into a visible, separately negotiated request.
Ticking the list produces the acceptance record — the same artifact that defines done also evidences it.

Tuning parameters¶

Granularity — few coarse criteria versus many fine ones. Finer criteria remove ambiguity but can themselves swell into a wishlist; coarse criteria stay light but leave edges to argue.
Bar height per criterion — how demanding each pass condition is set. The list fixes which conditions count; this dial sets how good each must be.
Sign-off owner — self-check versus independent client or QA acceptance. Independent sign-off makes the evidence trustworthy but adds a handoff.
Amendment rule — whether criteria can change mid-build and how. Locking the list protects the fence; allowing amendment keeps it honest when the item was mis-specified — but each change should be logged, not quietly absorbed.

When it helps, and when it misleads¶

Its strength is that it turns "is it done?" from a judgement call into an inspection, and turns silent scope growth into a visible add-on that has to be asked for. Its failure mode is criteria written as vague aspirations ("looks professional") that cannot be checked, so the fence leaks; and the classic misuse is padding the list after work has started to retroactively justify effort already spent, or letting "nice to have" criteria creep on until the checklist is itself the gold-plating. The discipline that guards against this is that every criterion must be a testable pass/fail agreed up front — the INVEST guideline's Testable clause.^[1]

How it implements the components¶

elastic_activity_boundary — the closed, per-item list is the boundary drawn around one otherwise-expandable deliverable; everything off the list is out.
completion_evidence_packet — the ticked checklist is the acceptance record that the item met its agreed terms.

It does not set the shop-wide sufficiency bar (independent_sufficiency_criterion) or keep it current (finish_line_recalibration_loop) — those belong to Definition of Done — and meeting the criteria is not itself the moment someone decides to stop polishing (stop_short_trigger); that trigger is pulled by Done-at-Eighty-Percent Demo.

Instantiates: Sufficiency-Bounded Work Containment — the checklist supplies the per-item fence and the acceptance record the archetype depends on.
Consumes: Definition of Done supplies the shop-wide bar these item-specific criteria sit on top of.
Sibling mechanisms: Definition of Done · Done-at-Eighty-Percent Demo · Opportunity-Cost Prompt · Agenda Exit Gate · Budget Ceiling with Returned-Funds Path · Last Responsible Moment Review · Marginal Value Burn-Down · Scope Change Ticket · Timebox with Early Exit Rule

Notes¶

Acceptance criteria and a Definition of Done are complements, not duplicates, and confusing them is the common mistake. The Definition of Done is one reusable standard that answers "was this built well enough for us to ship anything?"; acceptance criteria are per-item and answer "did we build the right thing for this one item?" A deliverable needs both — and needs them kept separate, so the global bar isn't quietly re-argued item by item.

References¶

[1] The INVEST guideline for user stories reserves its final letter for Testable — a criterion you cannot check is not a criterion but a hope. That testability requirement is exactly what keeps an acceptance list from sliding into an open-ended wishlist. ↩