Seann Hicks Portrait

Seann Hicks

Agile Scientist and Software Developer

Acceptance Criteria vs Definition of Done

In this article, we explore the crucial differences between acceptance criteria and definition of done in software development. Learn how these two concepts play unique and important roles in ensuring the success of your projects.

8-Minute Read

Banner Image

Photo by Tim Mossholder on Unsplash

Acceptance Criteria vs Definition of Done

While acceptance criteria are focused on meeting the needs of the customer, the definition of done is focused on ensuring that the product is of high quality and meets the team’s standards.

Acceptance criteria is list of quality measurements or outcomes for a Product Backlog Item. These outcomes are specific and only relevant for that backlog item. They will not make sense for other backlog items and they are used by the Product Owner and usually the Quality Assurance team to determine if the backlog item is fit for purpose; does the deliverable satisfy the customer need, is it good, does it work?

The definition of done describes the work process or workflow that ALL Product Backlog items go through to reach completion. The definition of done is not specfic to one backlog item, it applies equallty to all work items. It is used by the Product Owner to determine if a backlog item can be considered done but does not necessarily determine if a backlog item is usable by customers or is of sufficient quality to ship. The combination of achieving the acceptance criteria and the definition of done is needed to qualify a work item as ‘done’.

How does a project benefit from acceptance criteria

Agile and Scrum is primarily focused on getting work done. Acceptance criteria puts a scope ‘box’ around a work item. This creates focus and controls scope creep. Once the acceptance criteria is achieved the Product Owner can declare the work item complete. This is usually done with consultation from the reviewer (QA team members). The Scrum Master and Scrum team have a responsibility to ensure that the acceptance criteria on a user story or work item do not change as the work is being done. Changing the acceptance criteria may invalidate the estimated complexity of the work and jeopardize the sprint forecast.

Acceptance criteria helps the team determine the complexity of a work item so they can estimate the work effort to implement it. If a story is complex and requires a large amount of effort to implement, slicing the user story by breaking out the acceptance criteria into individual stories is a natural way to ‘slice’ the work item. See my article on slicing user stories for more information.

Acceptance criteria helps the work reviewers, which are usually Quality Assurance experts, determine how a work item will be validated as fit for purpose and behaves as expected. QA testers use the acceptance criteria and the solution design details to create test cases.

How does a project benefit from the definition of done

The definition of done describes the process that every work item moves through as it goes from being committed to a sprint backlog to being worked on and finally delivered to the customer. The project benefits from this consistent process through the following:

  • Work items move through a consistent process, so empirical (past history) information can be used to accurately estimate the work effort
  • The definition of done can be displayed as work item stages on a task board, making it easier to visualize the work
  • The team understands the expectation of what needs to be done for each work item
  • The Product Owner can determine that a work item is ready for release based on achieving the definition of done (satisfying the acceptance criteria is one element of a definition of done)

Why acceptance criteria is confused with definition of done

Acceptance Criteria is a quality measure and definition of done is a process measure. Process and quality are closely related, process changes are used to improve quality. This creates a temptation to use the process steps as acceptance criteria, especially the quality related steps, like inspections and reviews.

If your acceptance criteria looks generic, like a boilerplate list that applies to most or all of your backlog, then you are likely using your definition of done as your acceptance criteria.

See my deep dive article on Definition of Done for information on determining the definition of done for your project.

Improve your acceptance criteria by using a standard format

The “Given”, “When”, “Then” format is a standard format for describing acceptance criteria. Similar to the Conextra User Story format “As a”, “I want”, “So that” helps frame the customer, what they want and why they want it.

The “Given, When, Then” format explains how the outcome of a backlog item or user story will be inspected. This format can be difficult to grasp, but it works like this. The “When” describes the action the inspector will take to “test” the deliverable.

Given [Preconditions and assumptions about the state of the system]

When [Action or test activity that is performed on the system]

Then [Outcome or result that is expected]

“When” examples:

  • “When I enter my user id and and enter the wrong password”
  • “When I push the ‘submit’ button rapidly in succession”
  • “When I enter a large amount of text in the text box”

The “Then” describes the expected result from the deliverable.

“Then” examples:

  • “Then an error message is displayed and I am still on the login page not logged in”
  • “Then an icon is displayed indicating the submit is in progress and the page is no resubmitted”
  • “Then the text is truncated at the maxmimum length and coloured red to indicate the text is too long”

I recommend starting with the “When and Then” portion of the acceptance criteria, in most cases this is all you need. The “Given” describes any preconditions or assumptions that need to be met before the inspection action, the “When” is valid to proceed".

“Given” examples"

  • “Given I have a valid user id and I am at the login page and I am not logged in”
  • “Given I have not submitted the page and all fields are filled in and are valid”
  • “Given I am on a form with text boxes”

The “Given, When, Then” examples above combine into acceptance criteria, for example:

  • “Given I have a valid user id and I am at the login page and I am not logged in”
  • “When I enter my user id and and enter the wrong password”
  • “Then an error message is displayed and I am still on the login page not logged in”

Acceptance criteria are not the same as test cases

Acceptance criteria are not the same as test cases. Test cases are typically derived from the acceptance criteria, and I would suggest that QA personnel be engaged to help determine the acceptance criteria, but test cases are a step beyond acceptance criteria. Test cases describe the steps the tester takes to execute a test and includes the data that is being used to execute the test.

Test case creation takes the acceptance criteria and the solution design together to determine the test steps. The login acceptance criteria example above does not specify the exact error message, or how it is displayed. These details are determined once the user story implementation is in progress.

The test case steps for the login example might be

  1. Create a user with user id ‘user1’ and password ‘user1pass1’
  2. Navigate to the login page
  3. Ensure you are not logged in by checking the ’logged in’ status in the top right of the page
  4. Enter the user id ‘user1’
  5. Enter the password ‘password1234’
  6. Click submit
  7. Error message “Login incorrect” is displayed

Can we use test cases as acceptance criteria?

It seems that using the test cases as the acceptance criteria makes sense. If the work item passes all the tests it is ready to ship right? However, there is a nuance here that I alluded to above. The test cases require the acceptance criteria AND the designed solution to be written.

Because we are agile and we want to invest as little as possible into backlog items that are possibly moving up and down the priority list, it is important to minimize the time spent creating user stories. Lower priority product backlog items may never be implemented, so investing in a detailed design and test cases for these stories could be wasted investment. We want to use the Just-in-time model from lean manufacturing, create the designs and tests when we need them, that is, when it is time to implement the user story.


Acceptance criteria and definition of done are both important aspects of software development, but they serve different purposes. Acceptance criteria are a set of requirements that a product must meet in order to be accepted by the customer or user. They are typically written in collaboration between the development team and the stakeholders, and help to ensure that the product meets the needs of its users. On the other hand, the definition of done outlines the specific criteria that must be met by the development team in order for a feature or user story to be considered complete. It includes things like code review, testing, and documentation, and helps to ensure that the product is of high quality and meets the team’s standards.

Acceptance Criteria and the Definition of Done are closely related concepts in agile, and while they are both used the measure ‘completeness’, they serve two different purposes and are applied very differently in a project. They have unique benefits to a project and should be fully applied in an agile project.

See my other articles on user stories to help you create a solid product backlog:

Recent posts



I believe Agile Iteration is about validating assumptions and optimizing to meet business goals.