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.[n1]
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.
Also instantiates¶
Satisficing Threshold Design — Where the primary facet uses the checklist to fence and close one expandable deliverable, satisficing turns it into the evaluation control for a decision among candidates: the pass/fail list becomes the pre-committed rubric that separates the noncompensable floors a candidate must clear from the compensable preferences it may merely trade, and records the evidence for each. Its decisive contribution here is timing — the criteria are agreed and locked before any favoured option appears, so "good enough" cannot be re-drawn around the candidate someone already prefers. That is the archetype's defence against preference drift and post-hoc criteria manipulation: a candidate is accepted because it clears a standard fixed in advance, not because the standard bent to fit it. The same artifact that evidences scope containment in the primary facet here evidences that a closure was governed rather than convenient.
Related¶
- 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
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: The mechanism 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, so its operative form is a static or prospective information artifact.
Independent corroboration: The frozen evidence defines Acceptance Criteria Checklist as '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', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: A closed, per-deliverable checklist agreed before work and used to control scope and signoff belongs to project, contract, and agile work-management practice.
Related originating lineages:
- Computer Science & Software Engineering — User stories, INVEST, and software definitions of done supplied a prominent executable form of the checklist.
- Engineering & Design — Checklists and formal handoff verification supply the inspectable completion artifact.
- Law & Governance — Negotiated scope, amendment rules, and sign-off reflect contractual practice.
Review resolution: The bespoke closed checklist is project-management practice, with software, engineering verification, and contract acceptance as genuine convergent lineages; it is broadly reusable but not literally universal.
Review outcome: Reconciled after independent review; high confidence.
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.
[n1] 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. ↩