Is Definition of Done part of acceptance criteria?

No, the Definition of Done is not part of the Acceptance Criteria. While they both guide project progress, the Definition of Done applies to the project universally, defining when a task or project is considered complete. In contrast, Acceptance Criteria are task-specific, outlining specific requirements that each task must meet.

Could you provide an example of the Definition of Done?

A Definition of Done could include stages like the code being fully tested and debugged, all documentation completed, and client approval received. It's akin to an "all boxes checked" stage, for example, in software development, a task could be considered 'done' when the code is written, tested, reviewed, deployed, and documented.

What are the objectives of the Acceptance Criteria?

The primary aim of Acceptance Criteria is to define specific, measurable requirements for each task. This ensures the developed feature aligns with client expectations, fulfilling user requirements, and minimising the risk of misinterpretation or missed expectations.

Could you provide an example of the Acceptance Criteria?

Acceptance Criteria are specific and measurable. For instance, for a web development project, an Acceptance Criteria could be: "The mobile version of the website should load within 3 seconds and correctly display on all screen sizes." This provides a clear, measurable target for the development team to meet.

Definition of done vs acceptance criteria

A common question Product Owners ask us is what is the difference between definition of done vs acceptance criteria. It’s not a surprising question considering that some use the terms interchangeably but they do have two distinct meanings and purposes in the Agile world and together they work to set the team up for success.

When both the Definition of Done v Acceptance Criteria are not defined before work begins, one of two problems are likely to arise during an agile sprint:

The scope of work is extending past the expectation of the Product Owner, at the expense of other items in the Product Backlog.
The work is not completed to a level that the Product Owner finds to be the minimally acceptable level, resulting in rework being required, again at the expense of other items in the Product Backlog.

The Definition of Done

The Definition of Done is a checklist of criteria which every item in the sprint backlog must meet within the sprint to be considered done. This definition is different from one organisation to another and can even be different between teams at the same organisation. The key thing is that the Product Owner and the team agree on what the definition of done looks like for them and that they stick to it.

The Definition of Done is the same for every item in the sprint backlog no matter whether it is a bug, task or user story. It contains high-level items which apply to all work completed and its goal is clear, to ensure that the work is completed to a high standard, is well tested and could be released if the Product Owner chose to do so. It is the responsibility of everybody in the team to ensure that all the items in the Definition of Done are completed within the sprint.

An example of a Definition of Done is:

Work has been peer-reviewed for code quality and design successfully.
Testing by the QA team has been completed successfully.
Work is checked against the NZ Web Accessibility Standard, each criteria is met or discussed as acceptable not to meet.
Work is checked against the acceptance criteria, each criteria is met or discussed as acceptable not to meet.
Work completed works on supported browsers: Edge, IE11, the latest and previous version of Chrome, Firefox, and Safari.
Work follows best practice for SEO optimisation.
Work is responsive (e.g. works on mobile, tablet and desktop)
Client has tested and signed off the user story.

While the Definition of Done is mandatory to all work flowing through the project, Acceptance Criteria is only required when the user story requires further information to ensure it is completed successfully.

Acceptance Criteria

Acceptance Criteria are specific to each individual user story and exist to clarify what the team should be working on when they should stop working and ensure that the developers, designers, testers and Product Owner are all on the same page.

If you look at the user story, “As a user, I want to see search results relevant to my search, so that I can find the content I am looking for quickly” then an example of Acceptance Criteria would be:

Results are paginated to 10 results per page.
Search results are weighted to produce the most popular, relevant content first.
Search results can be filtered based on content type.

Sometimes items agreed to be within the Acceptance Criteria won’t be possible, and in this case, it is up to the developer to negotiate this with the Product Owner.

Conclusion

Once the Product Owner is happy that the user story meets the initial or revised Acceptance Criteria and the Definition of Done then they will sign off this user story, moving it to the done state.

Although Acceptance Criteria is not defined as part of Scrum is it a commonly accepted practice, helping the product owner and the team to fully understand the requirements of the user story and clarifying what a ‘done’ state looks like. Combine this with a well-defined Definition of Done and you can ensure that your team is always set up for success.

Do our definitions of Definition of Done and Acceptance Criteria match up with yours?
Do you want to find out more about Agile and how Somar works?
If you have any questions we'd love to hear from you!

Get in touch

When working on a project, two crucial terms to understand are "Definition of Done" and "Acceptance Criteria". Though they serve different purposes, they work together to ensure the project's success.

Definition of Done: This is a pre-established checklist that the team uses to confirm that a feature or user story is completed. It typically includes development, testing, and quality assurance processes. It marks the project's finish line and ensures that all necessary steps are taken before considering a feature to be 'done'.

Acceptance Criteria: These are conditions that a feature or user story must meet to be accepted by the client or stakeholder. They're used to assess the quality of the user story development, ensuring that each step along the way meets the user requirements and that the final product will satisfy the end user.

In summary, the "Definition of Done" provides a clear endpoint for the development process, while "Acceptance Criteria" guide each step of the journey, ensuring that all user requirements are met. Both are necessary for a successful project.

The main objective of the Definition of Done is to provide clarity and a shared understanding among team members about when a task or project is truly finished. This may include stages such as fully tested code, completed documentation, and client approval. It ensures all tasks are uniformly considered 'done', enhancing productivity and transparency.