The decision
Acceptance criteria describe the observable behavior a feature must deliver. They help business and development teams agree on completion before implementation begins. Write them around a user's task and meaningful outcomes rather than visual preferences alone.
In practice
For an expense submission, specify required information, permitted users, validation, approval behavior, and what happens after rejection. Include failure cases such as a missing receipt. A criterion should be testable without guessing what the author intended.
- Choose representative scenarios and identify the data needed to test them.
- Agree who approves the result and how changes affect scope.
- Keep criteria close to the feature brief so reviewers can connect the business need to the delivered behavior.
When to take the next step
Write criteria before estimating or developing an uncertain feature. Bring a realistic task, the permitted user, and the conditions that would make the result unacceptable.
Questions clients ask
How detailed should criteria be?
Detailed enough to verify important behavior and boundaries without prescribing unnecessary implementation choices.
Who writes them?
The business owner and delivery team should collaborate; the approver must understand what is being accepted.

