One of the common questions among many scrum teams is the difference between the definition of done and acceptance criteria and how they affect user stories. While acceptance criteria relate more to software development, the definition of done is unique to scrum.
People tend to mix these two terms, but they couldn't be more different, even though they have many things in common. Knowing how to tell these two apart will help you with their practical application.
Definition of Done (DoD)
Definition of Done (DoD) is designed as a list of items, each of which is used to validate product backlog item (PBI) or story. It exists to ensure that the development team agrees on the work they are trying to accomplish. Assuming a form of a checklist, it's used to check every user story for completeness or PBI – product backlog item. In other words, DoD is made to be applicable to all items in the product backlog, not just a single story.
To sum things up:
- The DoD is applied to product increments as a whole
- Usually implies that product increment is shippable
- It is defined in the Scrum guide
- Used as a method of communication among team members
Definition of Ready (DoR)
The definition of ready implies that stories have to be immediately actionable. In this case, the team needs to determine priorities and the required amount of work to finish PBI or user stories. Read stories have to be testable, clear, and, most importantly, actionable.
- An item is testable if you can find an effective way to check its functionality. The acceptance criteria ensure that you can test each story.
- A user story is clear if all scrum members know what it means. If you manage to adapt acceptance criteria and collaboratively write user stories, you will only facilitate clarity.
- A user story is actionable if you can complete it in one sprint, based on DoD. If this option isn't achievable, the story needs to be broken down further.
Simply put, Defifiniton of Ready (DoR) identifies criteria that a particular user story needs to meet to be considered for estimation and inclusion into a sprint.
Acceptance criteria
Agile development considers user stories as one of the leading development artifacts; however, scrum doesn't require teams to use either acceptance criteria or user stories. If PBI is too big to be put into a sprint, teams will break it down into user stories and further into a set of tasks.
Fundamentals of Agile Project Management
We often see acceptance criteria and DoD co-existing in a scrum development process because user stories encapsulate acceptance criteria. User stories will provide the type of functionality the team should deliver, while acceptance criteria provide guidance and details about those functionalities and customers' acceptance. Together, they make a deliverable.
To sum things up:
- Acceptance criteria apply to one Story/PBI only
- It is different for each story
- Used as a way of communication for all those involved to ensure that all story requirements have been met
Who's in charge of acceptance criteria?
In most cases, the product owner is responsible for specifying acceptance criteria and user stories. We often hear that acceptance criteria aren't mandatory; however, they're always recommended, primarily if the team works with various resources. Almost everyone agrees that acceptance criteria should be available before work begins, but the product owner has the final saying.
The responsible person for acceptance criteria in agile
According to many, acceptance criteria should come as a dialog between the scrum team and product owner. It isn't recommended for the product owner or the team to decide on their own.
Acceptance criteria should be an agreement between them, while both sides need to understand what they agree to. It is perfectly fine for the product owner to write some acceptance criteria, but this doesn't mean that the team understands them. A discussion needs to take place to ensure that all parties know what they're accepting.
The key difference between DoD and acceptance criteria
The difference between DoD and acceptance criteria is in their scope. While the definition of done applies to all your work, acceptance criteria are related to individual pieces of work, including user stories and, in some cases, PBI.
Definition of done in agile creates transparency for your team's shared understanding of what needs to happen with any item to be finished and meet the usable standard. In other words, DoD identifies factors you need for an increment to be released.
On the other hand, acceptance criteria focus on transparency and what needs to happen to complete one user story.
Other differences include:
- DoD covers quality and non-functional factors.
- Acceptance criteria determine functionality and the outcomes this functionality delivers to users.
What do DoD and acceptance criteria have in common?
DoD and acceptance criteria scrum work best when they are:
- Concise
- Clear
- Testable
- Updated frequently
- Agreed as a team
The development team needs to consider all this when estimating the size of each story and predicting stories they will commit to.
Creating the Definition of Done
Decide on DoD as a team. Even though relevant stakeholders, quality control, and product team have a saying about defining done, ultimately, it's down to the technical team to decide what done means. Be aware that this is a collaborative process, and without input from other teams, you will lack the support required to ship a feature.
Create a DoD checklist. Once you have a clear DoD in place, you need to make sure that these rules apply to every relevant issue or task in your sprint. Whether you are dealing with a massive feature release or a bug that needs to be fixed, it needs to go through this checklist.
Don't stress too much about a checklist. When your team decides on their DoD, you can easily get carried away and start thinking about what the ideal version may look like. Even though this can be a great exercise, you should be realistic about the things you include in your criteria. Keep in mind that too many DoD items can split your team's attention.
Each task should have its acceptance criteria. As you go through the sprint planning process, keep in mind that each issue should feature acceptance criteria and relevant information.
Check your definition of done against organizational requirements. The problem arises when teams are too focused on immediate tasks, and they forget about the larger goals and needs of their company. That's why, occasionally, you will have to check DoD against your organization's values so you don't miss any glaring issues.
Creating acceptance criteria
- Ensure that your criteria are well-defined, so all team members understand the ideas you are trying to convey.
- Keep criteria achievable and realistic. Define the minimum piece of functionality and stick to it.
- Discuss this matter with all stakeholders and ensure that acceptance criteria are based on consensus.
- Develop measurable criteria that will help you properly estimate development time to stay within time consensus and budget.
- Create an acceptance criteria checklist to see which user stores are covered.
