# How to write acceptance criteria, with examples > Acceptance criteria say when a task is done. Learn how to write them as clear true-or-false lines, with examples and a checklist for software teams. Acceptance criteria are the lines that say when a piece of work is done. Written well, they end arguments about “almost finished” before the work starts. Web page: https://kansohq.app/guides/how-to-write-acceptance-criteria Updated: 5 October 2026 ## What acceptance criteria are Acceptance criteria are a short list of conditions a task must meet to be accepted. Each one is either true or false when someone checks it. They sit on the task itself, so the person doing the work, the person testing it and the person who asked for it all read the same list. ## The rules for writing them 1. **One condition per line.** If a line has “and” in it, it is probably two criteria. 2. **True or false, nothing in between.** Avoid “fast”, “simple”, “intuitive” and “better”. 3. **Describe behavior, not construction.** “The user sees an error message” rather than “add a try/catch”. 4. **Cover the unhappy paths.** What happens with an empty field, no connection or no permission? 5. **Keep the list short.** Three to seven lines. More than that, and the task is too big. ## Two formats that work ### A plain checklist The simplest form is a list of statements, each checked off as it is verified. This is enough for most tasks. **Task: Show a banner when a sync conflict is found** > A banner appears when two edits to the same line conflict. > The banner names both versions and who made each. > Choosing a version closes the banner and keeps the choice. > If nothing is chosen within a day, the newer version stays and the banner remains. ### Given, when, then When behavior depends on a situation, write it as: **given** a starting state, **when** something happens, **then** an outcome. It is longer, but it leaves no room to misread the situation. **Task: Lock a page** > Given a page is locked, when a member tries to edit it, then the page stays unchanged and a note says it is locked. > Given a page is locked, when an admin unlocks it, then members can edit it again. ## Acceptance criteria and the definition of done Acceptance criteria belong to one task. The [definition of done](https://kansohq.app/guides/definition-of-done.md) belongs to the whole team and applies to every task: reviewed, tested, documented. Both have to be true before a task counts as finished. ## Mistakes to avoid - Writing criteria after the work is finished, to match what was built. - Criteria that describe the design (“a blue button in the top right”) instead of the outcome. - Leaving out the error and empty cases, then finding them in production. - Criteria nobody can check without asking the author what they meant. ## From vague to checkable | Vague | Checkable | | --- | --- | | The export is fast | Exporting a project of 500 pages finishes in under ten seconds | | Users can find things easily | Typing three letters in search shows matching pages within one second | | The error message is helpful | The message says what went wrong and what to do next, and keeps what the person typed | | Works on mobile | Every action on the page can be done on a 375 pixel wide screen without sideways scrolling | ## A checklist before work starts - Is every line either true or false when checked? - Does each line describe what a person or the system does, not how it is built? - Is there a line for the empty case and one for the error case? - Could a tester who has never met the author check each line? - Is the list short enough to hold in your head? If the answer to any of these is no, fix the line before the work starts. It costs a minute now and an afternoon later. ## Who checks them, and when The person who builds the task checks the criteria as they go, and ticks each when it is true. The tester or reviewer checks them again on the finished work. If a criterion turns out to be wrong or missing, change it on the task in the open, with a note, rather than quietly working to a different list. The criteria are an agreement, and an agreement changes only when everyone can see it change. ## Acceptance criteria in Kanso Every card on a [Kanso board](https://kansohq.app/product/boards.md) has a checklist for its acceptance criteria, and the card shows how many are met, right on the board. Start a feature from the [feature spec template](https://kansohq.app/templates/feature-spec.md), which has an acceptance criteria section ready for each task. ## Questions ### What are acceptance criteria? Acceptance criteria are the conditions a piece of work must meet to be accepted. Each one is a line that is either true or false when checked, and together they say when the task is done. ### How many acceptance criteria should a task have? Usually three to seven. If a task needs many more, it is probably too big and should be split into smaller tasks. ### What is the difference between acceptance criteria and a definition of done? Acceptance criteria belong to one task and say what that task must do. The definition of done belongs to the whole team and applies to every task, for example reviewed, tested and documented. ### Who writes acceptance criteria? The person who asks for the work usually drafts them, and the person who builds it and the person who tests it review them before work starts. ## Keep reading - [Definition of done vs acceptance criteria](https://kansohq.app/guides/definition-of-done.md): A definition of done is a team-wide checklist every task must meet. Learn how it differs from acceptance criteria, with an example list to adapt. - [How to write a product spec your team will read](https://kansohq.app/guides/how-to-write-a-product-spec.md): A good product spec is short, specific and honest about what is not decided. Learn how to write one, what to leave out and how to keep it current. - [What is a kanban board? A guide for software teams](https://kansohq.app/guides/what-is-a-kanban-board.md): A kanban board shows work as cards moving through columns. Learn how it works, how it differs from scrum and how software teams use it well. - [Feature spec template with acceptance criteria | Kanso](https://kansohq.app/templates/feature-spec.md): A feature spec template with how it behaves, acceptance criteria, edge cases and what you are not doing. Copy it, or start it as a page in Kanso. ## Parts of Kanso used - [Kanso Boards](https://kansohq.app/product/boards.md): A board for each piece of work. Cards carry a priority, an owner, a due date and the criteria that say when they are done. - [Kanso Docs](https://kansohq.app/product/docs.md): Pages with headings, to-dos, tables and code, kept inside the project they describe, next to its board and its release. [Kanso home, with plans and prices](https://kansohq.app/index.md)