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

The Definition of Done is the most crucial aspect for the team to build shippable increments of any product.

In the absence of a clear Definition of Done, there is no transparency if a Product increment is releasable, or the estimates could be unrealistic, the forecast of Sprint work could be inaccurate, or it could be difficult for the Product Owner to understand the progress on the Product or the inspection and adaptation at Sprint Review could be insufficient and so on.

A team's definition of done helps them continuously add value to the product. When iteration/sprint output meets the definition of done, the new value is available, and the stakeholders can access the deal whenever they choose.

One way to think about the meaning of done is as a checklist that helps us guarantee the quality of the product. This blog will discuss how to create a Definition of Done (DoD) and who makes one.

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 creating 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.

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 align 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.