When Is “Done” Really Done?Definition of Done and Acceptance Criteria

One of the most common problems in software development is that “done” means different things to different team members. For a developer, “done” may mean the code is written. For a QA engineer, it may mean the tests have passed. For a Product Owner, it may mean the feature meets expectations. When these three definitions do not match, problems are almost certain at the end of the sprint: unclear results, work items that come back, and bugs in the live environment. The Definition of Done (DoD) is the written form of this shared standard. Its partner, acceptance criteria, describes what one user story must do to be accepted. This guide explains both terms, shows how they differ, and gives practical examples.

To understand why the DoD is important, we first need to look at how teams grow. According to Bruce Tuckman’s model, teams go through four core stages:

In the Forming stage, team members get to know each other, roles are unclear, and everyone is looking for the answer to “What is expected of me?” In the Storming stage, different points of view turn into conflict. For example, the developer wants to deliver fast, while QA wants more detailed testing. Many “done” discussions happen at this stage. In the Norming stage, the team agrees on shared rules, and the DoD is one of the most concrete results of this agreement. In the Performing stage, the team does not debate the rules anymore. It applies to them naturally and works at a high pace.

For this reason, the best time to create a DoD is during the first sprints of a new team, when it moves from storming to norming. A DoD is not a document that you write once and forget. As the team matures, it should be reviewed in retrospectives and expanded.

The Definition of Done is a shared list of quality criteria that a work item (user story, task, or bug) must meet to be considered “done.” According to the Scrum Guide, the DoD is the formal description of the state of the Increment when it meets the quality measures required for the product. An Increment is created at the moment a Product Backlog item meets the DoD. A typical DoD list includes the following:

• The code is written and has passed code review
• Unit tests are written and passing
• Automation tests are updated and regression tests are run
• No critical or high-priority bugs are open
• The work is verified in the test environment, and the necessary documentation is updated
• All acceptance criteria of the work item are met

The importance of the DoD can be seen in these points: it creates a shared understanding and transparency in the team, it stops the quality standard from changing from person to person, it reduces “almost done” situations and growing technical debt, and it increases trust in release decisions. In addition, estimation and planning become much more realistic when the completion criteria are clear.

For example, in one project, developers considered a story done when the code was merged, QA counted it as done only after the regression tests, and the Product Owner expected the documentation to be updated as well. Because nobody knew exactly which steps were included in the work, the team could not give good estimates. Stories that were estimated too low did not fit into the sprint and were carried over to the next one.

The DoD is not just a checklist that you use at the end of a sprint. It plays a role in every stage of the process:

• Sprint Planning: The effort for each work item is estimated by considering all the steps in the DoD.
• During the sprint: The decision to close a work item is made according to the DoD criteria.
• Code review and PR processes: It is used as a checklist before merging.
• AI-assisted review: At the PR stage, AI checks whether the change meets the DoD items that can be verified automatically and marks any gaps as comments.
• Sprint Review and release: It confirms that the presented increment is ready for use.

The DoD is usually applied at three levels: story, sprint, and release. At the story level it is the checklist for each work item, at the sprint level it covers the whole Increment, and at the release level it covers the conditions for going live, such as final regression and deployment checks.

A good DoD comes from the team, not from a template. These steps help a team write its first version:

1. Bring the whole team together. Developers, QA engineers, and the Product Owner write the DoD together, so that each role’s idea of “done” ends up in the same list.
2. Start with what you already do. List the checks the team already runs, such as code review and unit tests, before adding new ones.
3. Make every item verifiable. Each item should have a clear yes or no answer. “Code is reviewed by at least one other developer” works; “Code is good quality” does not.
4. Automate what you can. Turn checks such as tests, code coverage, and security scans into quality gates in the CI/CD pipeline, so that the rules depend on the system, not on individual people.
5. Review it in every retrospective. Add items as the team matures and remove items that no longer add value.

When it helps

• A new team is moving from storming to norming and needs shared rules.
• Several teams work on the same product and need one quality standard.

When to be careful

• The list grows so long that nobody reads it before closing a work item.
• The DoD is copied from another team or a template without a team discussion.

Acceptance Criteria (AC) are the conditions that a single user story must meet to be accepted. They are specific to that work item. They are usually written by the Product Owner, but they are clarified together with the developers and the QA team in refinement meetings. The most important feature of AC is that they are testable. For this reason, AC forms the basis of test scenarios in QA processes.

In short, AC answer the question “Did we build the right product?”, while the DoD answers the question “Did we build the product in the right way?” For a work item to be truly done, both of them must be met.

A third term often appears next to these two: the Definition of Ready (DoR). The DoR describes when a backlog item is ready to enter a sprint, for example when its acceptance criteria are written, and its dependencies are known. The DoR controls the start of the work; the DoD controls the end.

Effective AC should be clear, measurable, and written from the user’s point of view. They should cover both positive and negative scenarios. For example, instead of “The search should return relevant results,” you should prefer “Searching for a product name lists all products whose name contains that text, with a maximum of 20 results per page.” The most common format is Given-When-Then, the same structure that Gherkin uses in behavior-driven development (BDD) tools. Here are two acceptance criteria examples for a login feature:

• Given the user is on the login page
• When they enter a valid username and password and click the “Login” button
• Then they are redirected to the home page
• Given the user is on the login page
• When they enter a valid username and an incorrect password and click the “Login” button
• Then the message “Incorrect password” is displayed, and the user cannot log in

The same format works for the product search example above:

• Given the product catalog contains items with “phone” in their name
• When the user searches for “phone”
• Then all matching products are listed, with a maximum of 20 results per page

This structure creates a shared language for development and testing, and it can easily be turned into automation scenarios.

From a QA point of view, the most important contribution of these two concepts is that they move quality activities from the end of the process to the beginning. Reviewing the AC during refinement helps the team find unclear points before any code is written. Including test activities in the DoD helps prevent testing from being squeezed into the last day of the sprint. Supporting the DoD with automated quality gates in the pipeline means that the rules depend on the system, not on individual people.

AI-assisted tools affect the DoD in two ways: they make it easier to apply, and they make its scope wider.

AI as an inspector. Before a work item moves to “Done,” AI can check many of the DoD items and the acceptance criteria of the user story. It can flag a criterion without a test, documentation that has not been updated, or a scenario that has not been covered. This makes the check consistent, whoever is working on the item. During refinement, AI can also find unclear AC and suggest draft scenarios in the Given-When-Then format, which improves testability. However, the final acceptance decision should be made with the Product Owner.

AI-generated output is also subject to the DoD. Code, tests, or documents written by AI should not be exempt from the same standard. In fact, extra items may be needed for this output: a human review of the code, a check for non-existent libraries or API calls (hallucinations), license and security scans, and confirmation that no confidential data has leaked into the prompt.

• Estimating only the coding work. Instead, include every DoD step in the estimate during Sprint Planning.
• Using the DoD in place of acceptance criteria. The DoD is the same for every item, so it cannot describe what a specific story should do. Each story still needs its own AC.
• Writing acceptance criteria that cannot be tested. “The form should be easy to use” cannot be tested. Rewrite it as a condition with a clear pass or fail result.

The Definition of Done (DoD) is the shared language of a team about quality. While Acceptance Criteria (AC) defines what will be developed, the DoD defines how the work will be completed. When effective AC and a clear DoD are used together, uncertainty decreases and quality increases. Moving quality activities to the start of the process and connecting the rules to the system with automated quality gates in the pipeline are the most concrete benefits of this shared language. AI can help automate the “done” decision but defining the criteria for this decision and taking responsibility for it remains the team’s job.