Acceptance Criteria and Definition of Done

Why “done” needs a definition

Ask three people whether a task is finished and you may get three answers. The developer says the code runs. The tester says it has not been checked. The customer says it does not do what they expected. None of them is lying; they are measuring against different, unstated standards.

Acceptance criteria and a definition of done are two ways of writing those standards down before the work starts, so that “finished” becomes something you can check rather than argue about.

Two different ideas

The two terms are often mixed up, but they answer different questions.

Acceptance criteria belong to one specific piece of work, such as a feature or a deliverable. They state the conditions that piece must satisfy to be accepted by whoever asked for it.

A definition of done belongs to the team or project. It is a shared checklist that applies to every piece of work, regardless of what it is. It covers the general quality steps the team has agreed on.

An everyday comparison: if you hire someone to paint a room, the acceptance criteria are specific to your room (“two coats, white, no paint on the skirting boards”). The definition of done is the painter’s own standard for any job (“furniture put back, dust sheets removed, tins sealed”).

Writing acceptance criteria

Good criteria share a few traits:

• Checkable. Someone can look at the result and say yes or no.
• Specific to the outcome. They describe what is observed, not how it is built.
• Agreed. The person requesting the work has seen and accepted them.
• Few and focused. A long list often means the work should be split.

Many agile teams use a “given, when, then” pattern, which describes a starting situation, an action and an expected result. For a login feature it might read: given a registered user with a correct password, when they submit the login form, then they are taken to their account page. A second criterion might cover an incorrect password and the message shown. The pattern is only a convenience; a plain numbered list works just as well if each line can be checked.

Hardware and process work uses the same idea with different wording. “The enclosure passes a fit check with the supplied board” or “the procedure can be followed by a new technician without help, in the time agreed” are both checkable conditions.

An illustration

Suppose a team is asked to add a “download report” button to a tool. A weak version of the acceptance criteria says: “Users can download reports easily.” Nobody can check “easily”.

A stronger version might say:

1. The report page shows a download button.
2. Pressing it produces a file in the agreed format containing the rows currently displayed.
3. If there is no data, the user sees a message instead of an empty file.
4. The button is usable with a keyboard alone.

The second version leaves less room for disagreement, and it gives the tester a ready-made set of checks. If a criterion turns out to be wrong, that discussion happens early, which is much cheaper than at delivery.

What a definition of done contains

The content depends on the team and the field, but typical items include:

• the work has been reviewed by a second person, for example through code review or a design review;
• the relevant tests have been written and pass;
• documentation affected by the change is updated, so that it does not become stale documentation;
• the change is merged into the shared, version-controlled main line;
• no known defects remain open, or any that do have been agreed and recorded.

In regulated or safety-related fields, the checklist is usually set by the applicable standards and the organisation’s procedures, and it is not for an individual to waive. Follow the rules that apply to your industry.

How the two fit together

A piece of work is done when it meets its own acceptance criteria and also satisfies the team’s definition of done. The first tells you the work does what was asked. The second tells you it was built and checked to the team’s usual standard. Passing one without the other is not enough: a feature that behaves correctly but has no tests and no documentation has a hidden cost, and a well-tested feature that does not do what was requested is simply the wrong feature.

Both link back to requirements. Acceptance criteria are often the testable form of a requirement, and requirements traceability keeps track of which tests demonstrate which requirements.

Common mistakes

• Writing criteria after the work. They then tend to describe what was built rather than what was needed.
• Criteria that restate the task. “The feature works” adds nothing.
• Letting the definition of done grow without limit. A checklist nobody can complete gets ignored. Keep it short enough to apply every time.
• Never revisiting either. If the same kind of defect keeps slipping through, that is a sign something is missing from the checklist.
• Skipping the conversation. The value is in the shared understanding, not the document. Reading the criteria aloud together often surfaces misunderstandings in minutes.

Practical habits

Draft criteria when the work is first planned, review them with the requester, and keep them with the task so they stay visible. Review the team’s definition of done now and then, for example after a project retrospective, and adjust it based on real problems. When a criterion cannot be checked, rewrite it until it can. That small discipline removes most of the arguments about whether something is finished.