# Write acceptance criteria that settle a task

Illustrative planning brief; no automatic product import.

Illustrative case: a password-reset task says “improve the reset experience.” The team needs to agree what the reviewer should actually inspect.

## Decision

Accept the task only after the agreed behaviors pass; record unresolved behavior as new scope.

## Owned work

- Confirm the successful path
  - Owner role: Engineer
  - Acceptance evidence: An invented valid account receives a reset link and can set a new password in the test environment.
- Check the boundary case
  - Owner role: QA reviewer
  - Acceptance evidence: An expired link receives the agreed safe error state without exposing account information.
- Record the acceptance decision
  - Owner role: Task owner
  - Acceptance evidence: The reviewer links the test evidence and records accepted or changes requested.

## Workflow

1. Replace “works well” with the user behavior that must be observed.
2. Choose a realistic failure case and agree the expected response before implementation.
3. Have the reviewer compare the evidence against the original criteria, not a moving target.

## Judgment

This checklist illustrates task acceptance; it is not a security audit or a complete password-reset specification.


## Filled illustrative decision

In the invented review, a valid reset link changes the password, while an expired link shows the agreed error without revealing account details. The reviewer accepts those bounded behaviors. A proposed redesign of the email is recorded separately, because it was not part of the original acceptance criteria.


## Workflow questions

### Should every task have many criteria?

No. Add the smallest set that distinguishes success from failure. A small copy edit may need only the final wording and approval.

### Can criteria change during work?

Yes, but document the change and reassess scope with the owner. Do not silently add acceptance conditions at review.

## Product connection

Use these behavior and boundary checks when reviewing a TeamBoostAI task description; a status change alone does not prove acceptance.

Confirm account availability before adopting this manual outline.