No one wants to spend hours on an assignment only to find out that what they made is not actually what the product manager was looking for. Two tools that prevent this problem are acceptance criteria and the Definition of Done (DoD).

While both spell out the standards that a piece of work must adhere to in order to succeed, the two types of requirements have different roles in helping your team succeed. Keep reading to learn the difference between acceptance criteria vs. Definition of Done and how to create them. 

What are acceptance criteria?

Acceptance criteria are requirements for a specific user story, feature, or product backlog item. The product owner is in charge of them, though they can and should collaborate with any relevant stakeholders and the team of developers when they create them. 

Acceptance criteria should give the team a clear picture of what they need to create in their work, keeping everyone aligned on that goal. These criteria help the team know if their work is on track or off course and whether the product owner, external clients, or other stakeholders will be satisfied with the end result. 

For example, say the development team needs to complete the following user story: “As a user, I want to be able to reset my password so that if I forget it, I can still access my account.” 

When the dev team is ready to begin work on this user story, the product owner might set the following acceptance criteria:

• If a user enters incorrect credentials, they will get an error message. 

• Users will be able to see and click on a link to a page that helps them reset their password.

• After resetting their password, users will get an email notification that their password was changed.

With these requirements in place, the dev team knows what the product owner is looking for, and they can proceed without any confusion. 

What is the Definition of Done (DoD)? 

While acceptance criteria are specific to each product backlog item, DoD is more akin to a checklist that you use for every piece of work you complete to ensure it meets the team’s quality standards and is ready to ship. The goal is that everyone on the team understands that a piece of work is not complete until it meets the agreed-on standards, and the DoD gives the team an easy way to check that nothing has fallen through the cracks. 

While the dev team needs to create and document their own DoD, it will probably include standards in the following areas:

• Code quality: The team should have a standard for ensuring tidiness in the coding.

• Testing and peer review: Each piece of work needs to prove that it’s up to snuff. 

• Security: Whatever your company’s policies around security, you need a benchmark to show that the piece of work will follow them.

• Integration: The code should work with the existing system without creating problems. 

• Ready for deployment: The piece of work should be shippable and ready to go before considered finished.

• Documentation: Don’t forget to document whatever your fellow developers will need about the work you completed. 

What is the Definition of Ready (DoR)?

Don’t mix up Definition of Ready with Definition of Done. While they’re both checklists that team members need to complete, DoR is used as you start a new user story, feature, or other piece of work. It’s the criteria you must meet to ensure that the work you do is a good use of the team’s time and resources.

For example, DoR could include standards on how well-defined and achievable the project’s goals are, what the acceptance criteria would be, if you have the resources and staffing you need to finish what you start, and what a realistic timeline would look like. 

In other words, Definition of Ready is what you go through to prepare to start something new, while Definition of Done is what you do to mark work as totally complete. 

How to create acceptance criteria

When you’re ready to create acceptance criteria for a product backlog item, here’s how.

1. Get the team’s input

Start by getting the right people in the room. You’ll need the product owner, developers, QA team members, and any other stakeholders who are affected by the product backlog item. When you collaborate on the acceptance criteria together, then the dev team has a better chance of producing something that satisfies everyone.

2. Focus on the user

The acceptance criteria should be targeted to this particular product backlog item. Don’t get sidetracked with other work. 

The best way to keep the acceptance criteria focused is to keep your attention on the user. If you keep them in mind while you create the criteria, then you shouldn’t end up with unnecessary requirements.

3. Make the requirements clear and measurable

Acceptance criteria only work if everyone can understand them. Make them clear, quantifiable, and concise. Give specific, testable ways that the team will know if the work meets the requirements, which will help the QA team verify it when it comes to them.

4. Don’t be afraid to update the criteria

Sometimes things change! If the project changes or you get new information, update your acceptance criteria accordingly. That way, the team doesn’t end up producing work to standards that are outdated. 

How to create a Definition of Done

Crafting a DoD is a big deal: You’re going to use it for every project, so you need to make sure you get all the relevant benchmarks. Go through the following steps to create your team’s Definition of Done:

1. Collaborate with your whole Scrum team

Everyone on the team will be affected by what you decide to include in your DoD, so get everyone’s input now. That way, you won’t miss something important, and everyone will be on board from the start.

2. Decide what’s most important

You can’t include everything in your DoD, even some nice-to-have items. That would simply take too much time to review, slowing down the process. You have to include what’s truly essential for every piece of work the team completes. Start by making a big list of everything you want, then pare it down to the true essentials that matter most to your organization, and write the standards in your DoD based on that.

3. Be specific

Your Definition of Done must be broad enough to apply to any project that your team works on, but if it’s too broad, your team won’t be able to use it. You need to include specific, measurable benchmarks for your team to check off. 

4. Set a regular time to review your DoD

Even if you create a truly good DoD for your team, circumstances still might change. Schedule a regular time to review your DoD and see if it still includes the necessary components—or if it has some standards that aren’t necessary. Be open to refining it when that would help your team produce their best work.

When crafting your acceptance criteria and DoD, you need to collaborate continuously and keep track of a lot of information.  Using a virtual whiteboard like Lucidspark can help your Scrum team easily create the DoD or acceptance criteria. Individuals can add their input to a document in real time or asynchronously and then vote on which tasks to prioritize. 

In addition, teams can design user story maps, sprint reviews, daily Scrum meetings, and more. The virtual whiteboard is perfect for collaboration and brainstorming, whether your team is working in the same office or in different countries. And once you’ve finished your acceptance criteria and DoD, everyone will be able to view the finished documents in Lucidspark to stay on the same page. 

So go ahead—create your acceptance criteria for each product backlog item and your Definition of Done for every project your team touches. With Lucidspark’s help, you can keep everyone aligned and every piece of work up to your organization’s standards, producing work that your team can be proud of.