Task management · Practical guide
Acceptance Criteria Examples: A Practical Writing Guide
By My First Task editorial team
Updated
The short answer
How to approach the work
Acceptance criteria answer 'What must this change do?' rather than 'Which coding steps will we perform?' A shared definition of done might require review and testing for every change, while a particular password-reset task needs its own success, expiry and failure behavior. Agree criteria before implementation so the owner and reviewer share the same scope. Avoid vague adjectives such as fast or intuitive unless you define a relevant measure. Given/When/Then is an optional format for describing a scenario, not a requirement for every task.
A practical sequence
- Identify the user's intended outcome and the boundary of this work item.
- Write observable conditions in plain language.
- Include a normal path and the failure cases relevant to the change.
- Specify test inputs, expected results and evidence where useful.
- Separate shared quality policy from item-specific behavior.
- Review criteria with the owner before work starts and record agreed changes.
Illustrative scenario · not customer research
Worked example
For a hypothetical password-reset page: a registered user requesting a reset receives the agreed next-step message; a reset link that has expired does not change the password; a valid link can be used only according to the product's approved security policy. The reviewer tests each behavior in the intended environment. The exact expiry duration belongs in the approved requirement, not an assumption made by the developer. General code review remains part of the team's definition of done rather than a substitute for these behaviors.
Acceptance criteria examples
Adapt this starting point to your own project. Examples describe a planning practice, not an automated app workflow.
| Vague condition | Observable alternative |
|---|---|
| The report works | For the agreed sample period, totals match the supplied source records. |
| The page is easy to use | The intended user can find the reset action and read its outcome message. |
| Errors are handled | For each agreed invalid input, show the expected message and preserve valid entries. |
| The task is tested | Record inputs, expected behavior, actual behavior and reviewer evidence. |
Common mistakes to avoid
- Writing implementation steps as if they prove user behavior.
- Adding new requirements during acceptance without discussing scope.
- Using a universal checklist instead of examining this task's risks.
Try the method with your own inputs
Questions answered
Are acceptance criteria the same as a definition of done?
Who writes acceptance criteria?
Can criteria change after work starts?
Apply it in a shared workspace
Keep the agreed owner, completion criteria and important decisions with the work. Explore the relevant My First Task feature.
Research context is available in our source library. The worked example above is an editorial illustration.
Continue learning
Definition of Done vs. Acceptance Criteria
A definition of done is the shared quality standard applied to completed work. Acceptance criteria describe the specific behavior or deliverables required for a particular task. Together they make completion more consistent and reviewable.
ExploreHow to Write a Task Description: Template and Examples
A useful task description states the result, why it matters, who owns it and how completion will be checked. Add the inputs, constraints and relevant links so the next person can act without reconstructing the request from chat.
ExploreBug Report Template: Reproduction Steps, Severity and Evidence
A useful bug report explains what happened, what should have happened, and how to reproduce the difference. Include the environment, impact and safe supporting evidence so the reviewer can investigate without guessing.
ExploreTurn the plan into shared work
Give each next action an owner, a completion condition and a realistic date. My First Task brings tasks, boards, project workflows and issue tracking into one workspace.