Acceptance Criteria

Definition

Acceptance Criteria are the explicit, testable conditions a deliverable must satisfy before a customer, product owner, or sponsor will sign it off. They translate an intent ("the user can reset their password") into the few unambiguous statements that decide whether the work is done. In agile teams they sit at the bottom of every user story; on capital projects they are written into submittals, inspection-and-test plans, and commissioning checklists. Wherever the rubber meets the road, acceptance criteria are the rubber.

Why They Matter

Without them, "done" is a matter of opinion. With them, "done" is a matter of evidence. Acceptance criteria pre-empt the most expensive class of disputes on any project: the ones discovered at handover. They also force the customer to think clearly about what they really want, before the team starts building the wrong thing efficiently.

How to Write Good Ones

• Given–When–Then is the workhorse format on agile teams. Given a starting state, when an action occurs, then an observable outcome must hold.
• Checklist style works for physical deliverables: each row is a yes/no condition a third party can verify on site.
• Each criterion must be independently testable. If you cannot describe how to test it in one sentence, rewrite it.
• Capture negative cases: what must the system not do, and what tolerances apply.
• Keep them small and specific. Five sharp criteria are better than fifteen vague ones.

Real-World IT / Agile Example

On a banking platform, a single story — "As a customer I can dispute a transaction" — went through three sprint reviews and was rejected each time. The fourth time the product owner brought eight Given/When/Then statements covering dispute eligibility, duplicate protection, audit logging, regulatory timing, and the customer-facing receipt. The team delivered it inside the sprint and it passed in 35 minutes. The story had not been harder than the team thought; the requirements had been thinner than the team believed.

Real-World Construction Example

On a 220 kV substation handover, the commissioning manager refused to accept the SCADA delivery because two acceptance criteria were missing: failover time under loss of primary RTU, and event-log time synchronization to UTC within 50 ms. The vendor argued the system was complete. The criteria, written into the original specification, were not. Three days of negotiation produced two pages of evidence — and a hard lesson that vague criteria cost more than precise ones.

Key Takeaways

• Acceptance criteria turn intent into testable evidence.
• They are written before the work, not after.
• They are owned by the customer, drafted with the team.
• They are the cheapest dispute-avoidance tool a project has.
• The same discipline applies to a user story and to a $20M commissioning package.

Expert Tips

• Review criteria during backlog refinement — too late by sprint planning, too early before that.
• Anchor non-functional criteria to SLOs so reliability stops being aspirational.
• For physical work, embed criteria in inspection-and-test plans signed by both parties.
• Trace each criterion to a test, an inspection, or a metric. If nothing measures it, it is not a criterion — it is a wish.
• When criteria balloon past ~8, the story is almost certainly too big and needs splitting.

Common Mistakes

• Treating the story title as the acceptance criterion.
• Writing implementation, not behaviour: "use a Redis cache" is not a criterion.
• Vague verbs — "supports", "handles", "manages" — that everyone reads differently.
• Missing the boring criteria: logging, error states, accessibility, timing.
• Letting acceptance criteria drift after sprint start without conversation.
• Confusing acceptance criteria with the Definition of Done. Criteria are story-specific; DoD is team-wide.

Practical Lessons Learned

• The minute spent sharpening a criterion saves an hour of rework.
• The customer who writes their own criteria becomes a better customer.
• The strongest predictor of a clean handover is whether criteria were testable on day one of the sprint or package.

Related Encyclopedia Entries

• Definition of Done
• Story Points
• Backlog Refinement
• Quality Gate
• Submittal Management
• Handover Management

Related Research Articles, Case Studies & Tools

• Project Controls Academy: Requirements
• Acceptance Criteria Templates
• Learning Tracks: Agile Delivery
• Books on Requirements Engineering
• Banking platform dispute story
• Requirements clarity and rework