In 2002, Bill Wake published in his article the inconsistencies that arise from certain terms that are used within teams, including that if “done.”
It took until 2007 for the Definition of Done (DoD) to be a widespread full-fledged practice.
But what is the Definition of Done and how can you incorporate it into your product’s lifecycle and development workflow.
Here is everything you need to know about the term and how you and your team can create it.
What is the Definition of Done?
Before we can properly get to utilizing the Definition of Done (DoD) it is important to understand what DoD is.
If you were to simply as a developer if they are “done” with a feature you would not get a straight reply, at least not one that satisfies you. This is of no fault due to the developer.
The question of whether a developer is “done” with a feature could mean anything from whether programming has been finished, whether deployment has taken place, whether the program has been tested, or any number of combinations of these acts.
This is where the DoD comes into play.
The DoD has been defined by Scrum.org as “a shared understanding of expectations that the increment must live up to in order to be releasable into production. Managed by the development team.”
In other words, the DoD is an agreed-upon set of tasks or items that need to be completed in order for a project or user story to be considered complete.
This definition should be applied consistently and should serve as the deciding factors of what is in progress and what is “done”.
While the particulars of each organization’s or development group’s DoD vary in the specifics and include individual variants, at the base of every DoD is that the code completes what it is aimed to do without affecting anything else negatively.
Why do You Need a Definition of Done?
Now that you know what a DoD is, you may still be wondering why your team needs to establish a DoD in the first place. After all, you do have acceptance criteria that each release has to adhere to.
We will talk about the differences between acceptance criteria and DoD below, but before we get to the specifics of how these two are different, here are some reasons why you need a DoD in the first place.
There are multiple different reasons why you and your team may want to establish a DoD. To name a few:
- If there is confusion over whether something is “done”, which can often be the case when you lack a common agreed upon DoD, there is cause for misunderstandings, conflict, and sometimes negative user experience.
- A common DoD also helps save time and allows resources to focus on innovation and execution rather than fretting over definition. This is only possible if there is a common DoD rather than a particular measure of ‘done’ for each individual project.
- The DoD builds a common understanding about the quality of the product and what classifies as complete for your entire team. This is important for each team member to be clear on what exactly they are working towards.
- The DoD acts as a clear goalpost and allows your team to finish exactly what they are working on and move on.
- The DoD is great to combat scope creep as you and your team can ensure that what was delivered at the end of a sprint is exactly what was agreed upon by your team and the project owner.
- The DoD also acts to limit rework and the cost and time associated with it, as there is an acceptance that the work is “done.”
Who Creates the Definition of Done?
Who creates or defines what “done” is for the team is dependent on the way your organization is structured and how it runs.
Typically, however, since the DoD is aimed at guaranteeing that releases work well and basic technical requirements are met, the technical team leads the creation of the DoD.
That being said, the definition may be steered by the Scrum Master or the head of engineering, or the lead of the technical team. However, the DoD should be a collaborative effort.
This is because you want widespread acceptance of the definition so you want to include other stakeholders as well as product and quality assurance teams to ensure that if the engineering team says something is “done” it is agreed upon by the whole extended team.
Components of the Definition of Done
When creating or deciding on the DoD there are certain components to include. For the purposes of this article, we will focus on the DoD in relation to product development.
In reference to product development, the DoD consists of three main components or elements to consider. These components include requirements both for the business or that are functional, quality, and non-functional requirements.
1. Business or Functional Requirements
When creating the DoD, you need to consider your business’ standard requirements. These requirements should add value to the product that is being created. This also ties in with the product’s functionality.
This particular component can take the form of user stories. It should be noted that the business or functional requirement aspect of a DoD may also carry overlap with acceptance criteria that we will discuss in detail below.
2. Quality
Quality standards can be subjective or could come from data.
It is the development team’s onus to ensure that the product is of maximum quality and is aligned to the rapid application development, coding language, and technical tools to build the product.
3. Non-Functional Requirements
Non-functional requirements may have overlap with the quality component of your DoD. They usually are incorporated into the acceptance criteria, but since are key to a product’s success are also part of the DoD.
Non-functional requirements are attributes or characteristics of the product that is essential for your project to be delivered although it may not add direct value to the business.
These could be things such as reliability, usability, or compliance and regulatory functions.
Acceptance Criteria vs Definition of Done
Now that you know what the DoD is, what its components may be, and who is in charge of creating the DoD there is another common question that many individuals and teams wonder about.
That is, what is the difference between acceptance criteria and the DoD. After all, in the information we have provided above we have mentioned a few ways that the DoD and acceptance criteria may overlap.
So, what is the difference between the acceptance criteria and the DoD?
This confusion often comes from the fact that individuals and teams often mix up that the DoD is in fact a project management issue rather than a quality control one.
Wouldn’t it just be easier and simpler to use the acceptance criteria to determine when something is “done”?
Well, no. Here is why.
There is a difference between a general DoD and the specific acceptance criteria of individual user stories.
The DoD is usually, apart from certain exceptions, applied as a standard for all the products that the technical team or engineering team is sending out.
On the other hand, the acceptance criteria are specific to the user story or the feature or issue being worked on.
As a reminder: a user story is a short, and simple feature description that is dictated by the customer or user.
When you consider who comes up with the DoD as compared to the acceptance criteria this too is different.
In the case of acceptance criteria, the acceptance criteria are defined by product management individuals. This criterion is created with input from the technical team as well as with reference to the individual use case and such.
For the creation of the DoD, while product management should review the definition, the ownership or management of the definition does not fall under their responsibility. We have discussed above in detail why and who is in charge of coming up and creating the DoD.
How to Create a Definition of Done?
Once you have understood what does and does not constitute the DoD it is time to understand how to go about creating a DoD.
This is simply a blueprint or guidance of how you and your team can approach deciding on the DoD and should not be taken as the rule of law.
Agreeing to what does and does not constitute as the DoD, who will do so, and how you will manage to do so is subjective and dependent on your organization and team in particular.
However, here is a guideline of things you need to remember and steps you can take to creating the DoD.
When creating the DoD there are two main elements that need to be remembered and taken care of. One is that everyone needs to be on the same page about the DoD. The second is that everyone should continue to be accountable for what was decided.
Step 1: Use Teamwork to Decide on the DoD.
The first step in ensuring that everyone agrees as well as accepts the DoD you create is by making the process one for the team and engaging the entire team when doing so.
Without input not from the technical team but also other teams and relevant stakeholders, you will not be able to get the support needed to deliver the feature or product in question.
Furthermore, this will create issues with stakeholders who may then have different expectations that were not included in the DoD and thus not considered.
Step 2: Make the DoD Accessible for Everyone.
Not only do you want to use the team to create the DoD you want what you decide upon to be accessible for everyone.
By making the DoD available for everyone you allow there to be transparency around the process and what elements are included for something to be “done” but also why those particular elements were chosen.
Having the DoD available also serves as a constant informant as to why a certain feature or product was or was not released on time.
As a golden rule, product delivery should be classified as “done” when the code does what it was meant to and does not negatively affect anything else in the process.
The details of this golden rule and the steps you take to achieve it are up to you and your team and what your DoD is.
Step 3: Ensure the DoD is Applied to Every Applicable Issue or Task in Your Sprint.
As mentioned, you do not want to create a DoD and forget about it. the DoD should be applied to every task or issue in your sprint.
Many teams fail to apply the DoD to the smaller bug fixes or issues.
If your team fails to apply the DoD to each release, even if it is completing the acceptance criteria of the specific issue or task, the pieces of the product while may be functional may not fit together effectively as a whole.
One way to ensure this is by working the DoD into the flow of work and processes for your team.
Why not use your project management tool to achieve this? nTask provides a great bunch of features that can help you embed the DoD into the workflow. Use the newly released Kanban board to ensure each task goes through each criterion of the DoD you and your team created.
To find out more about the features available in nTask and how you can incorporate them into your workflow check out the website here.
Step 4: Make Sure Your DoD is Realistic.
It is important to ensure that the DoD that you create is realistic in the criteria or elements that you include.
With an unrealistic number of items included in your DoD, you risk your team’s attention is diverted and thus lead to errors or ignoring items of the DoD altogether.
Try to make your DoD is the work required to meet the quality level that has been decided and not stuffed with too many unnecessary items.
Another thing to remember is to create your DoD to be realistic but be in tune with the larger goals and needs of your company or organization.
Conclusion
There you have it! everything you need to know about creating an essential DoD for you and your team.
Remember the DoD is important for multiple reasons including ensuring that the quality of your product and the process of your workflow runs smoothly. You need to make sure that the DoD is not simply a shared understanding but something that is spelled out and displayed so that it is incorporated into the product development lifecycle.
We hope this guide helped in informing you of how to do so.
Further Readings:
