“Is this task done?”
Answering this seemingly simple question requires checking if an item or product increment is complete or in progress. But it doesn’t work unless a team and its stakeholders have expressly defined it as “done.”
In Agile project management methodologies like Kanban or Scrum, “done” refers to the rightmost column on a visual board for completed items. Deciding on a clear definition of done (DoD) allows Agile teams, including DevOps and Scrum teams, to complete their items more efficiently.
This guide explains the DoD meaning in Agile methodologies and how to create one to make projects more effective and valuable.
Understanding the definition of done in Agile
A DoD is a set of criteria that a product increment must meet for the team to consider it complete and ready for customers. It is a shared understanding among the team members of when a product increment is ready for release, even when the increment is large and consists of many items. By clearly defining what “done” means to the project, an Agile team can focus on delivering value with every sprint and minimizing rework.
It is important to note that one person does not create the Definition of Done. Instead, it is agreed upon by the entire project team, including developers, testers, product owners, and other stakeholders. This ensures a smoother process during sprints since everyone is using the DoD as a guide alongside any checklists before marking an item as complete.
“If you deal with hand-offs to other teams, ensure your definition of done accounts for anything needed to ensure the other team is successful,” says Atlassian’s Modern Work Coach Mark Cruth. “Work with the other teams in the value stream to find out what you should be including in your DoD to support them.”
Definition of done examples
The DoD for a project varies depending on the type of project and the team involved. The following DoD examples illustrate how these definitions differ between project types:
On a mobile app development project, the DoD may include:
- All images are compressed.
All code is minified and gzipped.
On a software development project, example criteria in the DoD could include:
- All code has been thoroughly tested via unit, integration, and end-to-end tests.
Product increment has been deployed to a staging environment and tested by the team.
A generic project might have these as part of the DoD:
- All errors have been resolved.
All release documentation has been written and edited.
Definition of done vs. definition of ready
The DoD is a set of high-level criteria that defines when a product increment is complete. It ensures the quality and consistency of a deliverable. Teams typically use the DoD at the end of a sprint when checking the quality of a product increment.
In contrast, the definition of ready (DoR) is a set of low-level and specific criteria that applies only to product backlog items. The DoR defines when a backlog item is ready for a team to work on in an upcoming sprint. A team uses the DoR during the backlog refinement process at the start of a sprint.
Why is the definition of done important?
Having a DoD is vital to delivering a quality product that customers want because it clarifies when an item can be marked complete and is ready to be included in a product increment. A well-crafted DoD offers the following benefits:
Boosts quality: Checking every product increment against the criteria in the DoD ensures that Agile teams keep quality goals in mind throughout a product’s development. This guarantees that they consistently meet the quality standards required for release.
Minimizes risk: Following the DoD minimizes the risk of rework or the resulting delays it could cause since the team knows exactly what criteria an item should follow before it is marked complete. This ensures quality at every stage of the project.
Improves team alignment: Because the DoD is a shared understanding of what “done” means within the context of the project, teams can more easily focus on customer requirements and deliver value with every sprint.
Measures progress: Having a clear DoD allows teams to track the number of product increments that meet the criteria of “done”. For example, Scrum metrics may include velocity, which shows how many completed product increments a person delivers within a set time frame.
Steps to creating a definition of done
While the exact steps to craft a definition of done varies according to the team and the project, the process follows a similar pattern. These are the steps to create a DOD:
1. Work with the right team
It’s important to work with the right team members when creating a DoD since the criteria decided forms a shared understanding between all participants. This means including everyone who should have a say on how to define “done” for the project: product owners, the Scrum master, Scrum team members, testers, product managers, sponsors, and other relevant stakeholders.
Each team member brings their domain knowledge to the project and can weigh in on what criteria makes sense for their area of expertise. If you have the wrong team members or omit key team members, the DoD criteria may not be as comprehensive, resulting in a substandard product.
2. Establish the criteria
The largest task in defining “done” is establishing the criteria the team will use for the project. Setting the criteria for the DoD is crucial because it will affect the quality of the work done.
How will they know if each component of the project is complete? What conditions will indicate that this product increment is done? The criteria must be specific, measurable, attainable, relevant, and time-bound. To choose the appropriate criteria, the team must ask themselves two main questions:
- Is the criteria specific enough? Don’t be vague (All code tested); be specific (All code thoroughly tested via unit, integration, and end-to-end tests).
- Is the criteria customer-focused? A good example for this is “All documentation written and updated,” which should make it easy for the end user to find guidance when using the product.
“Remember that the definition of done is not the same thing as acceptance criteria,” explains Cruth. “The DoD is a set of activities the team believes need to be completed in order to call the user story “done” (which might include acceptance criteria) but it's not the same thing as saying the user story was implemented correctly.”
3. Build a completion checklist
A DoD criteria may seem more suitable for teams working on larger projects, but teams working on smaller tasks, issues, or errors can apply the same concepts to build a less extensive completion checklist. A completion checklist for every task or issue can ensure the team delivers high-quality work consistently.
4. Assign acceptance criteria to user stories
Acceptance criteria (AC) refer to the conditions that user stories must meet to become acceptable to customers. This differs from the DoD criteria because it deals with user stories or features instead of product increments.
But like the DoD, AC is also an agreed-upon criteria for determining if a user story or an individual task is done. If, for example, a user story is: “As a user, I want to be able to use a search field to find the product I am looking for.” The acceptance criteria could include:
- The search field is in the top navigation bar.
- The search begins after tapping the “Search” button.
The search field contains gray placeholder text that says “What are you looking for?”
5. Revise and update the DoD
The DoD isn’t a static document. Every bug or error found during a sprint is a quality issue that an unclear definition of done may have caused. . Updating the DoD then becomes crucial so the bug does not reoccur.
“The definition of done should be a living document, meaning as you learn new things about your work your team should update their DoD,” adds Cruth. “Consider reviewing the DoD every quarter to ensure it includes all items you think are necessary.”
Revise and update the DoD during sprint reviews to stay relevant to the project. As projects evolve and teams learn more about customer requirements, the DoD may also need revising to be achievable. Ensure there are opportunities for team members to suggest changes to the DoD during sprint reviews or backlog refinement meetings.
Ensure a well-defined DoD with Jira
For software teams, Jira makes creating your definition of done easy. Create custom fields or download an extension to create checklists on each Jira issue. Create a different DoD for different types of work by customizing Jira issue types.
Jira is trusted by millions of high-performing agile teams to support their program and project management needs, from Agile planning to sprint standups and everything in between. Try it for free.
Definition of done: frequently asked questions
Who is responsible for creating the definition of done?
The development team, led by the Scrum Master, typically creates a DoD. However, they should seek input from product owners, testers, and other stakeholders.
What is the difference between the definition of done and acceptance criteria?
The DoD is a set of high-level criteria for determining if a product increment is complete. It applies to all product increments and defines the overall quality of a product.
In contrast, acceptance criteria are low-level conditions that apply only to specific user stories or features. AC defines whether a user story is acceptable to a customer. An example of DoD could be “All documentation is written and updated. An example of AC could be “The link to the user documentation is accessible from the navigation menu.”
What are some best practices for creating a definition of done?
Define the criteria with your team: Defining the DoD should be a collaborative effort that involves the whole team, including developers, testers, product owners, and relevant stakeholders. Creating a DoD ensures a shared understanding of what it means for a product increment to be complete.
Keep it visible: The DoD should be available and visible during sprint planning or when there are discussions around estimating product backlog items. The team should be able to refer to it regularly. Print it out and hang it on the wall, or include it in a wiki or the project plan.
Be practical and realistic: The DoD should be achievable within the time frame and with available resources. More importantly, it should be relevant to what customers actually need.