Visit Blog Home

Definition of Done

This article discusses the Definition of Done in Scrum

In Agile development, where adaptability and continuous delivery are key, the Definition of Done (DoD) acts as a cornerstone. It’s more than a checklist — it’s a shared understanding of what “complete” means. This ensures transparency, quality, and consistent value delivery.

What is the Definition of Done?

The Scrum Guide defines the DoD as a formal description of the state of the Increment when it meets the quality measures required for the product. In simple terms, it’s a set of agreed-upon criteria that must be satisfied for a Product Backlog Item (PBI) to be considered “done.”

Sample Definition of Done for an E-commerce Website

Here’s a sample DoD for an e-commerce website. Each point can include specific details — for example, “Performance and Security Standards Met” might list page load time limits, vulnerability checks, and encryption criteria.

• Acceptance criteria met
• Performance and security standards met
• User experience (UX) and accessibility verified
• Documentation and code quality maintained
• Deployment readiness confirmed

Why is the Definition of Done Important?

The DoD drives success by:

• Ensuring Transparency: It provides a clear, shared understanding of what “done” means, eliminating ambiguity and fostering trust.
• Maintaining Quality: It sets high standards, reducing defects and rework.
• Boosting Predictability: A consistent DoD supports more accurate sprint planning and forecasting.
• Enabling Continuous Improvement: The DoD becomes a baseline for identifying improvements.
• Delivering Value: Each Increment is potentially releasable, ensuring value delivery.

Organizational Definition of Done: Minimum, Not Maximum

Many organizations create a company-wide DoD to promote consistency. However, this should define minimum standards — not maximum limits.

Rigid, overly detailed organizational DoDs can restrict teams and reduce flexibility. Instead, teams should build on the organizational baseline, adapting their DoD to fit their product’s unique needs. This balance preserves quality while empowering teams to respond to evolving requirements.

The organizational DoD should focus on essentials that apply to all products, like security scans and basic documentation guidelines.

Who drafts the Definition of Done?

The Scrum Team — including Developers, Product Owner, and Scrum Master — is responsible for the Increment and its quality. Together, they define and maintain the DoD.

• Product Owner: Ensures the DoD aligns with stakeholder expectations.
• Developers: Define the technical criteria needed to meet “done.”
• Scrum Master: Facilitates the process, ensuring the DoD is clear, realistic, and understood by everyone.

This collective responsibility ensures the DoD reflects the team’s combined expertise and remains achievable.

Why the Definition of Done Must Be Clear

Ambiguity causes misunderstandings, inconsistencies, and rework. A clear, precise DoD prevents this. We call such a clear and crisp DoD as a “Strong” DoD.

A Strong DoD:

• Uses SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound)
• Avoids jargon and unclear technical terms
• Is easily accessible to all team members
• Is reviewed and updated regularly

Clarity ensures everyone stays aligned, promoting consistency and minimizing errors.

How the Definition of Done Evolves

The DoD isn’t static — it evolves with changing technology, requirements, and team capabilities. As the team learns and grows, new criteria may emerge to enhance quality and efficiency.

Ways the DoD can evolve:

• Retrospectives: Regular reviews help identify areas for improvement.
• Stakeholder Feedback: External input reveals gaps or necessary adjustments.
• Technological Advancements: New tools may require updated criteria.
• Learning and Experimentation: Successful new practices should be integrated.
• Scaling: Organizational DoDs may need adjustments to support multiple teams.

By embracing continuous improvement, the Scrum Team keeps the DoD relevant and effective, supporting high-quality product delivery.

The Definition of Done is a foundation of Scrum. It ensures a shared understanding of quality and completeness. By creating a clear, evolving DoD, Scrum Teams enhance transparency, improve predictability, and deliver greater value to their stakeholders.

By WOA Author

Myth – Product Owner should not be invited in a Sprint Retrospective

Common Misconception

A Product Owner is considered a “Client” or “Customer”. So, most people feel, how can you invite a “Client” for an internal forum to discuss “what went well, what did not?”

Recommendations

• Most Product Owners indeed behave like a “Client” or a “Customer” instead of a Scrum Team Member. Therefore, the Developers do not consider the Product Owner a part of them and consider him/her as an outsider. The Product Owner should be first part of the Scrum Team and then be a “Customer” or “Client”
• Product Owners often ridicule the teams or shout at their teams for not understanding the requirements properly. Product Owners often escalate against the teams to the Line Managers of the Developers. This creates a divide between the Product Owner and the Developers. The Developers then don’t feel comfortable about opening up in front of the Product Owner. The Product Owner’s job should be to get the Developers to feel comfortable and put the “fear-factor” to rest. This means, the Product Owner should be empathetic, calm, show patience and be looked at as a Leader instead of a manager.
• Sprint Retrospective is a forum to see what went well and what did not go well. This increases the effectiveness of the next Sprint. If the Product Owner is not there in the Sprint Retrospective, then effectiveness improvement will be looked at only from the perspective of the Developers. The Developers are doing the technical work for the Product itself. So if the Product Owner is absent in a Sprint Retrospective, the effectiveness improvement cannot be done from the Product perspective
• Sprint Retrospective is a good forum to discuss the DoD (Quality Measure for next Sprint). If the Product Owner does not attend, the Sprint Planning of the next Sprint may be an issue since DoD is not finalized.

Conclusions

As a part of the Scrum Team, the Product Owner is a mandatory participant of the Sprint Retrospective. Sprint Retrospective is an excellent forum to thrash out any opinion differences and plan for improvements and everyone from the Scrum Team must participate.

Myth about Definition of Done being baselined before project starts

Common Misconceptions and negative implications

• Definition of Done is directly compared with Quality Criteria which was used in waterfall. Because of this teams tend to baseline the definition of done before starting the project
• By baselining the definition of done, product teams and delivery teams don’t get to iterate the quality criteria as they go-along
• Lot of time then gets wasted in trying to get the product too precise and the releases get delayed

Recommendations

• Definition of done should be emergent. That means the definition of done should get more and more stringent as the product maturity increases.
• There is no point in trying to make the Definition of done too stringent upfront. Instead one can always start with “the bare minimum” definition of done.
• As the product matures, it is often necessary to make the definition of done stronger. It makes sense then to make the definition of done stronger as you go along.
• However, one must understand that if the Definition of Done becomes stronger, then there may be undone work associated with the product and the product must be brought to the current definition of done. That means, all the undone work must be identified and put back into the product backlog.
• For example : One could start with a definition of done as
  1. Acceptance criteria for functionality is met
  2. User Documentation is completed 
  3. Integration testing is done
  4. Regression testing is done
• As the product matures, lets say, after 6-8 months, the volumes increase drastically and product becomes slow. Then it may be required to add performance testing into definition of done. So the new Definition of done could become.
  1. Acceptance criteria for functionality is met
  2. User Documentation is completed
  3. Integration testing is done
  4. Regression testing is done
  5. Performance testing is done
• So now one must understand that because Performance Testing is added to the definition of done, it is now required to add the “undone work” associated to the last 6-8 months of product that was already completed. And that means, we may have to dedicate some time in the upcoming sprints to get the product to the current definition of done.
• By doing this, it avoids a lot of initial wait time before we get the product into the market. In the above example if we would have added performance testing initially, a lot of time could have been wasted trying to do performance testing when it was not required. We could have missed the window of opportunity. Our competitors would have released the product earlier than us.
• It is not just the scope which is iterative and incremental in Scrum. Definition of done (Quality Criteria) is also iterative and incremental.