Protocol
Write acceptance evidence before implementation starts
Late acceptance criteria turn testing into negotiation.
When it fits
- A team agrees on a task but expects to decide what 'done' means near the end.
When to avoid it
- Discovery work can begin before final acceptance is known; do not pretend exploratory prototypes have production acceptance criteria.
Why it matters
Before implementation, write the observable outcomes that would show the need is met. Name the evidence when useful: test, demonstration, inspection, analysis, user task or data check. Include important negative and boundary cases.
Steps
- The team can design the verification without first asking what the finished feature was supposed to do.
An example
For a mass update, acceptance covers successful valid rows, rejected invalid rows, an audit result and behavior when the input is empty.
Check your result
The team can design the verification without first asking what the finished feature was supposed to do.
Keep this limit in mind
- Discovery work can begin before final acceptance is known; do not pretend exploratory prototypes have production acceptance criteria.
Connected ideas
Use beforeChoose the verification method while the requirement is still editable
Evidence and sources
NASA recommends identifying a verification approach for requirements and keeping each requirement uniquely identifiable with a definitive source.
The appropriate verification method and documentation depth depend on risk and project scale.
Appendix D: Requirements Verification Matrix · Requirements Verification Matrix
GOV.UK user-story guidance recommends recording the actor, needed action and goal, focusing on why the need exists, and using acceptance criteria to state observable outcomes that show the job is done.
User-story syntax is one framing method and is not appropriate for every technical, regulatory or infrastructure requirement.
Writing user stories · What to include; Focus on the goal; Acceptance criteria