Sign in Subscribe
Agile

THE DEFINITION OF DONE : A PILLAR FOR BETTER DELIVERIES

Loïc

• 4 min read
THE DEFINITION OF DONE : A PILLAR FOR BETTER DELIVERIES

Within Agile methodologies, the Definition of Done (DoD) plays a fundamental role in ensuring the quality of deliverables. It ensures that each increment produced by the development team meets a certain level of requirement before being considered complete.

What is the Definition of Done?

The Definition of Done is a list of criteria that each task, user story, or increment must meet to be considered "done." In an Agile framework, particularly in Scrum, a user story is not considered complete simply when it is coded, but when it is ready to be potentially deployed to production, thus meeting the criteria for quality, testability, and alignment with the initial requirements.

The criteria for DoD may vary depending on the team, product, or project but typically include items like code review, validation of acceptance criteria, unit and functional tests, updating documentation, or delivery to a stable environment.

How to Implement It?

  1. Collaborative Workshop to Define the DoD Implementing a DoD starts with a collaborative workshop bringing together the Product Owner (PO), Scrum Master, development team, and possibly other stakeholders such as QA (Quality Assurance). This workshop aims to collectively define the essential criteria for considering a user story as "done." This step is crucial as it aligns the expectations of all stakeholders. Therefore, it is an important prerequisite to achieve the required level of quality when developing a digital product.Indeed, Scrum states that at the end of each sprint, completed user stories that are marked as DONE should be tested, documented, and potentially ready to be delivered to the production environment. Beyond the validity of the acceptance criteria, the DoD may contain any relevant elements to ensure the quality of the product in question.Furthermore, the Definition of Done helps align technical and business teams on the expected and acceptable outcomes at the end of the sprint, avoiding many back-and-forths and disappointments.Finally, any functionality that does not meet all DoD criteria should not be presented during the sprint review and is considered incomplete.
  2. Adapt the DoD to the Team and Project Context Each team and project has specific needs. The DoD should reflect the team's maturity, the complexity of the product, and technical constraints. It is recommended to start with a concise list of essential criteria and then evolve it over the course of sprints based on feedback.
  3. Communicate the DoD Once the DoD is defined, it must be shared with all stakeholders. It's essential to explain the approach to them so they understand the quality criteria that the deliverables will meet. This also reassures them about the robustness of the development process.
  4. Review and Continuous Improvement The DoD is not set in stone. At the end of each sprint, the team should revisit the DoD to check if it remains relevant or if it needs adjustments. This regular review ensures that the DoD evolves along with the product, technologies, and the team's skills.

Pitfalls to Avoid

  1. Too Long and Detailed List A common pitfall is creating a DoD with an endless list of criteria, which can make validation impossible within a sprint. An overly detailed DoD can hinder the development process rather than support quality. It is crucial to start simple and refine it over time.
  2. Not Involving the Entire Team The DoD should result from collective thinking. If it is imposed without consultation, it may be poorly received or unsuitable. The definition workshop must include all voices to ensure that the criteria are realistic and accepted by the team.
  3. Neglecting Communication A DoD that is not shared with external stakeholders (clients, management, etc.) can lead to misunderstandings and disappointments. It's important to communicate the DoD effectively so that everyone understands what is considered "done."
  4. Not Evolving the DoD Needs and contexts change, and the DoD must follow this dynamic. Failing to revise it regularly can lead to obsolete or unsuitable criteria, reducing its effectiveness.

Tips for an Effective DoD

  1. Start Simple and Evolve There's no need to create a perfect DoD from the start. Begin with the essential criteria and then evolve it as the team matures.
  2. Review the DoD at Each Sprint Use the sprint retrospective to review the DoD: Is it still relevant? Does it need adjustments? This regular review helps keep the DoD aligned with the project's needs. This practice is often overlooked, and teams tend to forget it, but the DoD must evolve regularly with the team; it’s one of the pillars of Agile, which is empirical and incremental!
  3. Use Fun Tools To facilitate the creation of the DoD, you can use tools like the DoD Kards card game. These playful tools can help engage the team and explore different criteria interactively.
  4. Ensure the DoD Remains a Facilitator The DoD should remain a tool to ensure quality, not an obstacle to delivery. Make sure it does not become an excessive constraint for the team.

Conclusion

The Definition of Done is an indispensable tool for Agile teams, ensuring that delivered increments meet a certain level of quality. By defining it collaboratively, adapting it to the needs of the project, and reviewing it regularly, it becomes a real asset for success in an Agile framework. However, it is essential to remember that an effective DoD should be simple, evolving, and well-communicated to play its full role without becoming an obstacle to development.