“It’s done” can mean code merged, page published, form submitted or customer need met. Those are different milestones. Agreeing the finish condition before work starts keeps a review from becoming a fresh scope negotiation.
Write acceptance around the outcome
For a form, test a valid submission, an invalid field, confirmation, routing and ownership of the next action. For a landing page, confirm approved content, links, mobile layout, analytics requirements and the intended next step. For a catalogue update, check the correct product, variant, document and visible attributes. For a publishing workflow, test who can create, review, approve and release a representative item.
State the environment, sample data, browser or device range where relevant, and who performs the review. Separate acceptance checks from optional polish. If an expected result depends on third-party access, mark that dependency rather than letting the task appear complete by assumption.
Record the handover
Completion includes what changed, where it lives, how to verify it and who owns it next. Note known limitations, outstanding defects and any monitoring or operational step. The record does not need to be elaborate; it needs to let the next person understand the change without reconstructing a week of chat.
A practical inspection
- Describe the user-visible outcome.
- List positive and negative scenarios.
- Name reviewer, environment and evidence.
- Mark dependencies and exclusions.
- Record release, owner and known limitations.