Skip to main content

What is the Definition of Done?

Let’s start with some clarification. The Definition of Done (also called D.o.D. or DoD) is a cornerstone concept in Agile. At its core, it establishes when a product backlog item is complete.

Understanding the Definition of Done in Agile

A D.o.D. is a set of criteria or a checklist that a product backlog item must meet before the team considers it ready for customers. The Definition of Done fosters a shared understanding among team members on the completion status of a product backlog items and consequently the increment, even for large and complex projects with many moving parts. By clearly defining what “done” means for the project, Agile teams can deliver value consistently throughout each sprint and minimise rework.

A single person doesn’t create the DoD. Instead, it’s a collaborative effort involving the entire project team, including developers, testers, product owners, and potentially other stakeholders. This collaborative approach ensures a smooth workflow during sprints, with everyone using the DoD as a guiding principle alongside checklists before marking an item as complete.

Definition of Done Examples

 
The specific criteria within a DoD will vary depending on the project type and the team involved. Here are some examples to illustrate this point:

Mobile App Development Project DoD:

  • All code meets the Product Backlog Item (PBI) acceptance criteria
  • Another team member has reviewed the completed code
  • All unit tests have been completed
  • All images are compressed.
  • All code is minified and zipped.
  • The Product Owner has reviewed the completed PBI
  • All release documentation is written and edited.

Software Development Project DoD

  • All code meets the Product Backlog Item (PBI) acceptance criteria
  • Another team member has reviewed the completed code
  • All code undergoes thorough unit, integration, and end-to-end testing.
  • The Product Owner has reviewed the completed PBI
  • The product increment is deployed to a staging environment for team testing.
  • All release documentation is written and edited.

 

Why is the Definition of Done Important?

 
Having a well-defined DoD is crucial for avoiding confusion among Developers and the Scrum Team and ensures the delivery of a high-quality product that meets customer needs. It clarifies when an item can be marked complete and incorporated into a product increment. Here are some key benefits of a well-crafted DoD:

Enhanced Quality

Agile teams prioritise quality goals throughout development by measuring each product increment against DoD criteria, ensuring consistent delivery that meets release quality standards

Reduced Risk

Following the DoD minimises the risk of rework and potential delays. With clear criteria, the team understands precisely what’s required for an item to be considered complete, fostering quality at every project stage.

Improved Team Alignment

Since the DoD establishes a shared understanding of “done” within the project context, teams can maintain a clear focus on customer requirements and deliver value throughout each sprint.

Progress Measurement

A defined DoD allows teams to track the number of product increments that meet the completion criteria. For instance, Scrum metrics like velocity can showcase how many completed product increments a team delivers within a specific timeframe.

 

Steps to Creating a Definition of Done

 
While the exact steps to crafting a DoD may vary based on the team and project, the process generally follows a similar pattern:

1. Work with the Right Team

When creating the Definition of Done (DoD), involving the right team members is essential. This means including everyone invested in defining what it means to be “done” for the project. The team should include product owners, Scrum masters, team members, testers, product managers, sponsors, and other relevant stakeholders. Each team member brings their expertise to the table, providing valuable insights into the criteria that make sense for their area of focus. Omitting key team members can result in an incomplete DoD, which could lead to a substandard product.

 

2. Establish the Criteria

Defining “done” is a crucial activity that involves establishing the criteria that a team will use to determine project completion. The criteria should be clear and concise, as they directly impact the quality of the final product. The team needs to decide on the conditions to indicate that a project component or a product increment is complete. To do this, they should follow the SMART criteria, which means the criteria should be Specific, Measurable, Achievable, Relevant, and Time-bound.

 

To select appropriate criteria, the team should ask themselves two key questions:

  • Are the criteria specific enough? Avoid vagueness (e.g., “All code tested”). Instead, be specific (e.g., “All code thoroughly tested via unit, integration, and end-to-end tests”).
  • Is the criteria customer-focused? A good example is “All documentation written and updated,” which ensures the end user can easily access guidance when using the product.

 

3. Build a Completion Checklist

DoD criteria might seem more suited for larger projects. However, teams working on smaller tasks, issues, or errors can utilise the same concepts to create 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

Similar to the DoD, AC is also an agreed-upon set of criteria used to determine if a user story or individual task is considered “done.” For example, if a user story states: “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 positioned in the top navigation bar.
  • The search begins upon tapping the “Search” button.
  • The search field displays grey placeholder text that reads “What are you looking for?”

 

5. Revise and update the DoD

The DoD is not a static document. Every bug or error discovered during a sprint is a potential quality issue that might stem from an unclear definition of done. Updating the DoD becomes crucial to prevent similar bugs from recurring.

 

The Definition of Done (DoD) is a dynamic document that should be updated periodically as new information about work is gained. Teams should review and update their DoD every quarter to ensure it includes all necessary items.

It is important to regularly review and update the Definition of Done (DoD) during sprint reviews to ensure it remains relevant to the project’s ongoing development. As the project progresses and teams better understand customer requirements, the DoD may need to be adjusted to remain achievable. Creating opportunities for team members to suggest changes to the DoD during sprint reviews or backlog refinement meetings is crucial.

 

Ensuring a Well-defined D.O.D.

Software development teams can utilise project management tools to streamline the creation of a Definition of Done (DoD). These tools offer the flexibility to create custom fields or download extensions to generate checklists for each issue. You can also customise issue types to create different DoD variations for various work types.

Agile teams often use tools to manage programs and projects, including sprint planning and stand-up meetings.

 

Who is responsible for creating the definition of done?

The development team, led by the Scrum Master, usually leads in creating the DoD. However, they should actively seek input from product owners, testers, and other stakeholders.

 

What’s the difference between the definition of done and acceptance criteria?

The Definition of Done (DoD) is a set of high-level criteria determining whether a product increment is complete. It applies to all product increments and establishes the overall quality of a product. On the other hand, acceptance criteria (AC) are specific conditions that apply only to individual user stories or features. AC defines whether a user story meets customer expectations. For instance, 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: Creating a DoD should be a collaborative effort that involves the entire team, including developers, testers, product owners, and relevant stakeholders. This collaborative approach ensures a shared understanding of a complete product increment.
  • Maintain visibility: It is important to ensure that the Definition of Done (DoD) is easily accessible and visible to the team during sprint planning sessions or while discussing the estimation of product backlog items. The team should be able to refer to it frequently. You may consider printing it out and displaying it prominently or including it in a team wiki or project plan.
  • Be practical and realistic: The DoD should be achievable within the project’s timeframe and with available resources. More importantly, it should be relevant to what customers need.

By following these steps and best practices, Agile teams can establish a clear and well-defined Definition of Done that fosters quality, reduces risk, improves team alignment, and ultimately leads to the successful delivery of high-value products.

If you’re interested in learning how to become an expert in Agile, check out our training below!

Further Agile Scrum Training

 Online Professional Scrum Master Training II (PSMII)

 Online Professional Scrum Product Owner (PSPO)

 Professional Scrum Product Owner Advanced (PSPO-A)

 Online Professional Agile Leadership Essentials (PAL-E)

 Applying Professional Scrum (APS)

The Scrum Events

What does a Product Owner do During the Sprint?