How to Write Acceptance Criteria for a Small Task
Acceptance criteria explain how a requester and worker will agree that a task is complete. Without them, a review can become a subjective debate after the time has already been spent. Criteria do not need to anticipate every possible detail, but they should cover the outcomes that matter, how they will be checked and what should happen when an edge case appears.
· By Nothing.gripe
Describe observable outcomes
Use a clear statement of what the final result must include. For a site test, name the pages, expected behavior and supported devices; for a data task, specify the required columns, validation rules and format. Avoid criteria that simply repeat the original request or use adjectives without examples.
- Use a checklist that a second person can follow.
- Name the expected output format and any required components.
Define the quality boundary
Explain which errors are unacceptable, which differences are acceptable and what standard applies. A research brief may require source links for factual claims; a design task may require particular dimensions and brand assets. If the work is subjective, agree on examples and the decision-maker before production.
- Use examples or test cases to clarify ambiguous language.
- Separate required features from preferences.
Specify proof and review
State which files, screenshots, reports or links demonstrate completion, who reviews them and when feedback is expected. Proof should establish the outcome without requesting unnecessary sensitive data. For software or data tasks, include relevant tests; for research, include sources and limitations.
- Tie each criterion to a simple method of verification.
- Set a reasonable review window and correction process.
Plan for defects and changes
A defect means an agreed requirement was not met; a changed requirement adds or changes scope. Define how each will be handled. If new information makes the original criteria unsuitable, pause and agree a revision rather than silently changing the acceptance test after delivery.
- Document the baseline criteria before work begins.
- Use an agreed change request for material scope updates.
Acceptance checklist for a small deliverable
Before anyone starts, finish each sentence in plain language:
- Output: “The submission includes [exact file, format, link or count].”
- Correctness: “It passes when [testable facts, formulas, fields or requirements] are correct.”
- Completeness: “It covers [included items] and clearly excludes [out-of-scope work].”
- Proof: “The doer supplies [sample, screenshot, test result or explanation] without exposing private data.”
- Review: “The requestor checks it against these criteria within [time period].”
- Revision: “A revision covers missed criteria; a new requirement is handled as a scope change.”
- Handoff: “The final files and any agreed instructions are delivered through [safe channel].”
A criterion should be observable and tied to the agreed brief. “Make it excellent” is not enough on its own; explain what a reviewer can actually test.
Put the advice into practice
Define outcomes people can observe, specify how they will be checked and distinguish defects from new requirements. Good acceptance criteria reduce disputes without trying to predict every possible scenario.
Define acceptance before work begins
Write down what a correct delivery contains, what evidence to provide, the file or format required, and how many revision rounds are included. Clear criteria help both sides resolve disagreements without moving the goalposts after submission.
Common questions
Can acceptance criteria change after work starts?
They can, but both sides should agree on the impact on price, timing and proof before the change applies. Silent changes create disputes because the worker is judged against a target they never accepted.
How many criteria are needed for a simple task?
Use the minimum that makes completion unambiguous. A small task may need only a few bullets, while a higher-risk task needs more detailed tests and exception handling.