Who Creates Definition of Done: The 2023 Guide

How to Create a Definition of Done (DoD)?

The development or project team creates the Definition of Done (DoD). It is a shared understanding of what constitutes a completed and acceptable deliverable for a specific product, feature, or iteration. The DoD should be agreed upon by all stakeholders, including the development team, product owner, and any other relevant parties. It is typically used in Agile development methodologies such as Scrum.

The First Step

If the Organization has a standard defined for all its products, the team must start by inheriting those standards as their Definition of Done for an increment. For example, organizations might have expressed criteria like quality, security, privacy, availability, etc., for all the products it builds irrespective of the technology or usage. When the teams begin product development, they should start from this list. If multiple Scrum Teams are working together on a product, they must mutually define and comply with the exact Definition of Done.

The Second Step

If it is not an organizational standard, the Scrum Team must appropriately create a Definition of Done for the product. Even if they have followed the first step in building their initial DoD, they can still add items relevant to the product. Facilitate the Creation and Evolution of your team's DoD

a) Invite the Relevant Stakeholders to the Discussion: The entire team, including the PO, SM, and Developers, should participate in the creation of the DoD. If multiple teams work on the same product, all sections should participate. When an increment meets the definition of done, the stakeholders should be able to access it to provide feedback quickly. To ensure that the purpose of doing accomplishes this, key stakeholders should be invited to create the definition of done. Stakeholder groups that should be represented might include end users, product support staff, and system architects.

b) Cover All Aspects: Have the participants identify everything needed before any change to the product could be part of a new increment. Recall that an increment should be shippable and readily available to stakeholders. Each piece of work goes on a sticky note (physical or virtual). Be as specific as possible. If a team member says "testing," get clear about what that entails and write detailed sticky notes such as:

Each acceptance criteria have an automated regression test.
All acceptance/regression tests are passing.
Unit test coverage is more excellent than 80%
All unit tests are passing.
No open P1/P2 defects
User Guide is written for the functionality.

Put all the sticky notes on a wall (again, physical or virtual). Keep asking if there is additional work needed. Are there sign-offs? Documentation updates? Compliance requirements? Eventually, the team will have captured it all. At this point, you have your definition of done.

Definition of Done (DoD) is Not a One-time Process

The Definition of Done (DoD) is critical to any software development project. It establishes the criteria that must be met before a feature or product can be considered complete and ready for release. However, it's not a one-time process. The DoD should be regularly reviewed and updated to ensure it stays aligned with the project's goals and requirements.

Evolution

The team might start with the not-so-strongest DoD. As a starting point, the team might start with a more straightforward definition of done that only includes the work that can be completed each initial sprint. Since the unit is new, it could be too much of a task to meet every possible aspect of quality, availability, security, privacy, etc.

The team might still be getting acquainted with the domain and technology. In this case, the product's actual release might require more than pushing a button. You might have to capture the additional work needed to release something new into production. Put it on the wall and label it "Release Work." But, the team strives to make the DoD more stringent over time, adding more work items related to quality, performance, availability, privacy, security, etc.

Continuous Improvement

The definition of Done is not static. The teams continuously Inspect & Adapt to improve the DoD. Therefore, the DoD should be evolving. Doing grows for the team is to discover weaknesses or gaps. For example:

In a product backlog refinement session, the team might notice that a particular Acceptance Criteria is almost universal, so they add it to the definition of done.
In sprint planning, the team might notice some vital work that isn't currently captured in the definition of done.
In the daily scrum, the team might surface impediments that a more robust definition of done could avoid.
In sprint review, the team might discover missed stakeholder expectations and decide to add stakeholder sign-off or user acceptance testing (UAT) to the definition of done.
In a sprint retrospective, the team might identify some ways a more robust definition of done might have prevented the introduction of bugs during the sprint.

The best time to Inspect & Adapt the existing DoD is the Retrospective meeting. The teams can discuss what was done and how it was done. And if necessary, certain items could be added to the DoD.

Have DoD Before First Sprint/Iteration

If you are working with a new team, facilitating the creation of their definition of done should be one of the first orders of business. Don't worry about getting it perfect or ideal; it's more important to be realistic. Then you begin evolving and improving the definition of done over time. If the meaning of done is so weak that the team can't create a usable increment at least once a sprint, then improving the definition of done should be a high priority.

Find Our Upcoming Training

Beginners	Intermediate	Advanced
Scrum Master (PSM) Training	Leading SAFe® 5.1 Training with SAFe® Agilist Certification	Implementing SAFe® 5.1 Training with SPC Certification
Product Owner (PSPO) Training	Certified Agile Coaching (ICP-ACC) Training	Agility in the Enterprise (ICP-ENT) Training
Professional Scrum with Kanban™ (PSK) Training	Advanced Scrum Master (PSM-II) Training	SAFe® Lean Portfolio Management (LPM) Training
Agile Fundamentals Bootcamp (ICP) Training	Advanced Product Owner (PSPO-A) Training	SAFe® Agile Product Management (APM) Training

Agilemania

Agilemania, a small group of passionate Lean-Agile-DevOps consultants and trainers, is the most trusted brand for digital transformations in South and South-East Asia.

Who Creates the Definition of Done and How to Create One?

CATEGORY LIST

Popular Post

TAGS