Definition of Done

What is the definition of done?

The Definition of Done (DoD) refers to a set of agreed-upon criteria that must be met before a project, user story, or backlog item is considered complete. It’s an important concept in Agile methodologies, especially within the Scrum framework.

These success criteria vary among teams and organizations but typically include requirements like completed coding that meets business and functional requirements, comprehensive testing with no major defects, complete documentation, and readiness for general availability.

Key characteristics of the definition of done:

Comprehensive checklist: The DoD typically includes a range of activities like code writing, testing (unit, integration, end-to-end), reviewing design documents, and ensuring all release documentation is complete.
Shared understanding: It’s not created by a single individual but agreed upon by a cross-functional team, including developers, testers, product owners, and other stakeholders.
Flexibility and iteration: The DoD can vary from team to team and product to product, adapting to their specific needs and requirements. It’s a living document that may evolve as the project progresses or the team’s understanding of the product deepens.

Definition of done vs. acceptance criteria

While the DoD sets the minimum standards for a deliverable to be considered complete and shippable, acceptance criteria are more specific to each user story or feature. They outline the detailed conditions or functionalities that need to be satisfied for a user story to be accepted by stakeholders.

Why do we need a definition for done?

Having a definition of done ensures that everyone on the team is aware of what tasks need to be completed before a piece of work is classed as “done” and doesn’t require any more work. A shared understanding means there are no surprises and last-minute rushes when the feature is launched. The definition of done is an important tenet in various agile development methodologies – you can see some examples here.

Definition of done is a checklist of things to complete before something is "done". — The definition of done is a checklist of things to complete before something is “done”.

Having a clear DoD is essential for ensuring consistent quality and completeness across projects. It helps teams maintain steady and predictable progress, improve the accuracy of estimates, and work together more effectively by providing a shared understanding of what constitutes a completed item. This clarity helps in avoiding misunderstandings, conflicts, and negative user experiences, which could impact the product’s success.

Here are the main reasons why having a clear and concise Definition of Done can be a benefit to Product Managers:

Ensures completion and higher quality:

The DoD provides a clear set of criteria that a task must meet for a team to consider it complete. This ensures that all necessary steps, including functional, technical, and non-functional requirements, are met. This encourages the creation of high-quality products.

Facilitates efficient completion of tasks

By having a clear DoD, Agile teams, including DevOps and Scrum teams, can complete their tasks more efficiently. It serves as a guide, clarifying the work needed to be done and creating a shared understanding among the team and stakeholders.

Minimizes rework and miscommunication

A well-defined DoD saves teams from countless headaches, miscommunications, and rework, as it provides a shared vision of what ‘finished’ looks like. This clarity is essential, especially in environments where team members have varying perspectives on what constitutes a completed task.

Supports Agile principles

The DoD allows teams to focus on delivering features quickly with appropriate levels of quality assurance, aligning with key Agile principles of speed, delivery, and continuous iteration. It fosters confidence within product development teams to innovate while maintaining quality assurance during delivery.

Reduces unplanned work and delays

Applying a complete DoD eliminates the need for additional “hardening sprints” or “release sprints,” which are often used to finish incomplete work from previous sprints. This not only aligns the release date with the actual project progress but also minimizes last-minute surprises and unplanned work.

Promotes transparency and accountability

The DoD creates transparency about what the team is doing in every sprint and what is delivered. It also minimizes the delay of risk by ensuring that risky items are inspected, adapted, and improved early in the project, reducing the likelihood of issues emerging in production.

Reflects team agility, quality, and maturity

A comprehensive DoD is a reflection of a team’s agility and its ability to produce high-quality work. It shows the team’s capability to complete features within a sprint and release them immediately to production, meeting all necessary quality standards.

Who creates the definition of done?

Typically, the engineering team, often led by the Scrum Master or head of engineering, takes the lead in defining DoD. However, it’s crucial to make this a collaborative effort, involving product managers, quality assurance teams, and other relevant stakeholders. This collaborative approach ensures broad acceptance and alignment on what qualifies as “done” across different departments.

The creation of the Definition of Done (DoD) in Agile and Scrum methodologies is a collaborative process that involves various members of the project team. The process of defining the DoD is not the responsibility of a single individual but rather a collective effort to ensure that it encompasses all necessary aspects of the project.

The process of creating the Definition of Done is iterative and should be revisited regularly to ensure it remains relevant and effective throughout the project. By involving a diverse group of team members in its creation, the DoD becomes a robust guide that enhances the efficiency, transparency, and quality of the Agile project.

How to create a definition of done

Creating an effective definition of done (DoD) is a critical step in Agile and Scrum methodologies. Here’s a general guide to developing a DoD, based on best practices and expert advice:

Assemble the team: Gather all relevant team members, including developers, testers, Product Owners, and Scrum Masters, for a collaborative discussion about the DoD.
Understand product and customer needs: Begin by discussing the customer needs and product requirements. Understanding these aspects helps in aligning the DoD with the product’s objectives and stakeholder expectations.
Define specific criteria: Identify specific criteria that a task, feature, or product increment must meet to be considered complete. This includes functional, technical, and quality standards. Ensure that these criteria are clear, achievable, and relevant to the project’s goals.
Include all relevant team members in the discussion: The DoD should be created with input from all the involved team members to ensure it reflects the realities of the task and the team’s capabilities. This also helps in gaining team buy-in and commitment.
Document the DoD: Once agreed upon, document the DoD in an accessible format for all team members. This could be on a shared digital platform, a wiki, or an Agile project management tool.
Ensure clarity and conciseness: The DoD should be clear and concise to avoid misunderstandings. It should be detailed enough to provide guidance but not so detailed that it becomes impractical to use.
Seek cross-functional collaboration: In cases where multiple teams are involved, it’s important to ensure that the DoD is aligned across these teams. This is crucial for maintaining consistency and quality in larger, more complex projects.
Regularly review and update: The DoD is not a static artifact and should be reviewed and updated regularly. This helps in ensuring that it remains relevant and effective throughout the lifecycle of the project.
Communicate the DoD: Ensure that the DoD is communicated effectively to all team members and stakeholders. This might include discussions in Agile ceremonies, training sessions for new team members, and visual displays in team working areas.
Incorporate feedback: Encourage and incorporate feedback on the DoD from team members. This can lead to improvements and ensure that the DoD continues to meet the team’s and product’s needs.

By following these steps, you can develop a robust and effective DoD that guides your teams toward success.

What should be included in the definition of done?

It’s easy to consider that completing all the code changes means a new feature is done, but it’s important to also consider all testing, documentation, and operational tasks.

For the feature to be used by customers, it must also have technical and functional documentation. Depending on how integrated the product team is with non-technical functions, the definition of done may also include pricing, sales and marketing copy, website update, etc – the information needed to conduct a successful launch.

A typical DoD includes a checklist of items such as peer-reviewed code, code deployment to the test environment, successful regression and smoke testing, updated documentation, and stakeholder approval.

It’s essential to keep the definition as simple and concise as possible, focusing on the minimum steps required to move a product item to completion.

This list varies depending on the project’s nature and the team’s specific requirements, but typically includes the following elements:

Code quality and completeness: This includes the completion of coding tasks, adherence to coding standards, and resolving any technical debt that may have accumulated.
Testing and validation: The DoD should cover various types of testing, such as unit tests, integration tests, and end-to-end tests, to ensure that the code works as intended and that all features are functional.
Documentation: Proper documentation, whether it’s technical or user-focused, should be completed and updated. This can include release notes, user guides, or internal documentation for future maintenance and development efforts.
Performance and security: Ensuring that the product meets performance benchmarks and security standards is crucial, especially for software development.
User acceptance: The product or feature should meet all the acceptance criteria specified by the product owner or stakeholders and should be validated by them for its intended use.
Compliance and standards adherence: The product should comply with relevant industry standards, legal requirements, and organizational policies.
Integration and compatibility: Ensuring that the new increment integrates seamlessly with existing systems and doesn’t introduce compatibility issues is crucial.
Review and approval processes: There should be a formal process for reviewing and approving the completed work, which may involve peer reviews, managerial approvals, or client sign-offs.
Deployment and release readiness: The product increment should be ready for deployment, which includes being tested in a staging environment and ensuring that all deployment processes are in place.
Customer and stakeholder feedback: Incorporating feedback from customers and stakeholders, especially in iterative Agile methodologies, is key to ensuring that the product meets external expectations.
Non-functional requirements: This includes aspects like usability, scalability, and maintainability of the product or feature.

The DoD should be tailored to the specific context of the project and the team, and it should be reviewed and updated regularly to ensure its continued relevance throughout the project lifecycle. It acts as a critical tool to ensure that all work meets a baseline standard of quality and completeness before being considered “done”.

How to communicate the definition of done?

Effectively communicating your definition of done effectively is crucial for ensuring that all team members understand and adhere to the criteria you’ve established for completing tasks.

Here are some of the most important ways to communicate the DoD:

Document and make it easily accessible: Ensure that the DoD is clearly documented and accessible to all team members. This could be through shared digital platforms such as wikis, intranets, or project management tools like ProdPad. Having the DoD readily available allows team members to refer to it as needed.
Integrate it into Agile ceremonies: Discuss the DoD during key Agile ceremonies such as sprint planning, daily stand-ups, and sprint reviews. This consistent reinforcement helps in embedding the DoD into the team’s working practices and allows for any necessary clarifications or updates to be communicated.
Include it in training and onboarding: Include the DoD in the onboarding process for new team members. Providing training sessions or informational resources about the DoD helps newcomers understand the team’s standards and expectations right from the start.
Incorporate feedback mechanisms: Establish channels for team members to provide feedback on the DoD. This approach promotes continuous improvement and ensures that the DoD meets the evolving needs of the project and the team.
Clearly explain changes: If there are updates or changes to the DoD, clearly and swiftly communicate these changes to the team. Explain the reasons for the changes and how they impact the team’s work.

Effectively communicating the DoD is not a one-time activity but an ongoing process that requires continual attention and adaptation. Regular reinforcement, updates, and open channels of communication are essential for ensuring that the DoD is understood and effectively implemented by the entire team.

Examples of the definition of done

Examples of the Definition of Done inevitably vary depending on the nature of the project, the team, and the organizational standards. Some common examples include:

Software development project example:

All code is written and follows coding standards.
Code is reviewed and approved by peers.
Unit tests are written and pass successfully.
Integration and end-to-end tests are conducted and pass.
Documentation (technical and user-focused) is completed and reviewed.
The feature is deployed to a staging environment and tested.
Security checks are completed, and any vulnerabilities addressed.
Performance benchmarks are met.
User acceptance testing is completed, with the product owner’s approval.
The feature is merged into the main codebase and ready for production deployment.

Mobile app development example:

All images are compressed to optimize performance.
Code is minified and gzipped for efficiency.
The app passes all functional and non-functional testing.
Compatibility with targeted mobile devices and OS versions is confirmed.
User interface and experience meet the design specifications.
App Store or Play Store guidelines are adhered to for deployment.

Marketing or creative project example:

All content is created and aligns with brand guidelines.
Visuals and multimedia elements are produced and approved.
Market research and target audience analysis are complete.
Campaign strategies are developed and reviewed.
Digital assets are optimized for various platforms.

Examples at various levels of Agile product management:

Scrum team level: Includes unit test passage, code reviews, met acceptance criteria, functional test passage, and user story approval by the Product Owner.
Enterprise/Product Management level: Encompasses stakeholder demo and acceptance, UX design review and acceptance, integration test passage, compliance with requirements, and feature documentation completion.
Portfolio management level: Focuses on aligning with market needs, achieving target architecture design, releasing and evaluating MVPs, conducting user tests and surveys, and identifying no new requirements.

These examples demonstrate that the DoD is a versatile and dynamic tool that can be adapted to fit the specific needs and objectives of various types of projects and teams.

Do you ever need to change the definition of done?

Yes, the definition of done can, and arguably should, evolve. You’ll need to revisit and potentially revise it as the team’s skills and processes mature, as well as when there are changes in project requirements or organizational objectives.

This evolution can be prompted by a variety of reasons, including:

Changes in project requirements

As a project progresses, its requirements might change, necessitating adjustments to the DoD. This could be due to shifts in market demands, stakeholder needs, or technological advancements.

Team feedback and learning

Agile and Scrum are iterative methodologies that focus on continuous learning and improvement. As the team gains experience and learns from past sprints, they might identify areas in the DoD that need refinement to better align with their working practices and project goals.

Enhancements in team capabilities

Over time, a team’s skills and competencies may evolve, allowing them to take on more complex tasks or implement more rigorous quality standards. This growth can lead to an expansion or modification of the DoD to reflect the team’s enhanced capabilities.

Adaptation to technological changes

With the rapid evolution of technology, teams may need to update their DoD to incorporate new tools, platforms, or methodologies, ensuring that the project remains cutting-edge and efficient.

Compliance with Updated regulations and standards

In industries that are heavily regulated or where standards frequently change, the DoD may need to be updated to ensure compliance with these new regulations or standards.

Feedback from retrospectives

Regular sprint retrospectives provide an opportunity for teams to reflect on what’s working well and what could be improved. Insights from these sessions can lead to modifications in the DoD to better support the team’s workflow and project outcomes.

Scaling Agile practices

As organizations scale their Agile practices across multiple teams or departments, they may need to standardize or modify the DoD to ensure consistency and alignment across these larger groups.

Risk management and mitigation

Over time, teams may realize that certain risks or issues are not adequately addressed by the current DoD. Adjustments may be necessary to ensure that the DoD effectively mitigates these risks.

The process of changing the DoD should be collaborative, involving all relevant team members to ensure that it continues to reflect their needs and the project’s objectives. Regular reviews of the DoD are a best practice in Agile environments, ensuring that it remains relevant, comprehensive, and effective.

Common mistakes in applying the definition of done

When applying the definition of done, there are many common mistakes and pitfalls that teams often fall foul of, including:

Vague or ambiguous DoD: A DoD that is too vague or lacks specificity can lead to misunderstandings about what constitutes a completed task. Your DoD needs to be clear and unambiguous to avoid differing interpretations among team members.
Overly complex or detailed DoD: Conversely, a DoD that is overly complex or detailed can be daunting and may lead to inefficiency. It should strike a balance between being comprehensive and practical.
Failure to regularly update: Not updating the DoD to reflect changes in project requirements, team capabilities, or technological advancements can render it obsolete or irrelevant. The DoD should evolve alongside the project and the team.
Lack of team involvement in creating the DoD: If the DoD is imposed by management without team input, it may not accurately reflect the realities of the team’s workflow or capabilities. The DoD should be collaboratively developed with input from all team members.
Inconsistencies across teams: In organizations with multiple teams, inconsistencies in the DoD can lead to friction and complications, especially in projects where these teams need to collaborate.
Ignoring non-functional requirements: Focusing solely on functional aspects and ignoring non-functional requirements like performance, security, or usability in the DoD can lead to issues in the final product.
Not aligning the DoD with customer or stakeholder expectations: The DoD should reflect not only the team’s understanding of “done” but also align with customer or stakeholder expectations. Misalignment here can lead to a product that doesn’t meet external needs.
Insufficient communication: Failing to adequately communicate the DoD to all team members and stakeholders can lead to gaps in understanding and application. Effective and regular communication of the DoD is essential for its successful implementation.

Avoiding these common errors in establishing the definition of done requires ongoing attention, collaboration, and a willingness to adapt. Regularly reviewing and refining the DoD, and ensuring clear communication and understanding of it across the team, are key steps towards its successful application by Product Managers.

Back to The Product Management Glossary

The Outcome