We have learned all about the scrum roles, events, and it’s artifacts. Apart from these terms, the one you will hear most often is the concept of “Done” . In this tutorial, we will find out what “Done ” means for Scrum teams, and why it’s so important. We will go through the below topics of Definition of Done.
- What is the Definition of Done (DOD)?
- Why Do we need the Definition of Done?
- Examples of Definition of Done
- Who Defines Definition of Done in Scrum
- When do we create a Definition of Done?
- Definition of Done Vs. Acceptance Criteria
- Done Vs. Done Done
- Common Questions and pitfalls on Definition of Done
What is the Definition of Done (DOD)?
As per the Scrum guide, when a product backlog item or an increment is called out as Done, then everyone in the Scrum team must understand what Done means.
It is quite an open-ended definition, and rightly so. The definition of done will vary across organizations, and it may also differ within the organization across different scrum teams.
Why do we need the Definition of Done?
Let’s understand this with a simple example. Assume that the Scrum Team is working on a product increment to create login functionality for the e-commerce product. At the end of the sprint, the team claims that they are “Done ” with the product increment. What does this mean? Is the login functionality deployed to production? Has this been performance and security testing? Or the team meant that they finish the development and testing, but perf, security, and deployment to prod are pending. Can you see this ambiguity?
While there is no one fit all definition of done, the definition must be clear to all the stakeholders. It ensures that when the Scrum team calls out a product increment as “Done”, everyone has the same shared understanding of what this means. It is crucial to ensure that we have artifact transparency.
Examples of Definition of Done
The definition of Done is usually a checklist of all the work that team needs to do before it can call the product increment as “Done” . A sample checklist could be:
So for a product increment to be marked as Done, the team would need to ensure checking everything on this list. If anything gets missed, then the product increment will not be marked done, and the team will need to either move the entire product increment or a part of it to the next sprint.
Again, this is a sample checklist, and it will vary across scrum teams and organizations.
Who Defines Definition of Done in Scrum?
Scrum team defines the definition of done. They are the ones who will be accountable to meet this definition, so it’s essential that the team creates it and agrees to it. In some cases, the definition of done can be at an organization level or at a product level (where multiple scrum teams are working on the same product). Even in such cases, the scrum team would need to agree to it and make modifications as required to fit their product increment needs.
When do we create the Definition of Done?
As you would have figured out, the team would need to use this definition in the first sprint when they would mark the first product increment as done. That means the definition of done should create before the first sprint or latest within the first sprint itself. If we create it before the sprint, then it should be walked-through the new team members who have joined later.
Definition of Done Vs. Acceptance Criteria
People often confuse acceptance criteria with the definition of done.
Each backlog item that is working in a sprint (Stories) has a set of acceptance criteria that the product owner defines. Whether the product builds rightly is determined by these acceptance criteria.
As we have seen in the checklist, the acceptance criteria validation will happen anyway as part of the definition of done. Still, there are other items in the checklist that needs to finish before we can call the product increment as done.
Another significant difference that we should note is that the acceptance criteria are at a story level. Each development team member that works on a story will have an acceptance criterion that needs to fulfill. But can the team member complete all the other checklist as part of DOD on his story? Probably not! E.g., he may not be able to deploy his story stand-alone. It needs some other dependant functionalities that the other team members work upon.
The Definition of Done, on the other hand, is at the Product Increment level. It means that the entire checklist needs to complete for the product increment (which is usually the collective work of the whole development team in a sprint)
The Definition of Done can also partially apply to individual stories. E.g., A developer will mark the story “Done” only when the checklist related to code completion, Test completion, and Acceptance Testing is complete. However, the other checklist, like deployment to production and Non Functional Requirements, might be applied at the product increment level.
Done Vs. Done Done
It’s important to note that the Scrum Guide doesn’t define “Done Done”. However, you will see multiple teams using this term.
So what is this Done that we do two times! Some teams like to have a bifurcation in the actual doneness process. Its basis is on Development complete Vs. Test complete, even though this is an inefficient process.
In some cases, the product increment happens with all the checklist. Still, due to the nature of the product and development (e.g., external dependencies), the product increment cannot deploy to production in the same sprint. As such, the team denotes Done done as something which is complete but does not deploy to production. However, it marks it Done when it deploys to production.
Common Questions and pitfalls on Definition of Done
Now that we have understood the concept of Definition of Done let’s have a look at some of the common questions and pitfalls that we have on DOD
Can we change the DOD?
We should not change the Definition of Done to ensure that we can show the work as completed. It’s usually a common mistake that some teams do, but it could lead to degradation of quality. However, DOD could evolve. As the scrum team matures, they could have more stringent criteria for higher quality. E.g. The DOD criteria for not having P1/P2 defects could expand to P1/P2/P3 defects.
The practice is usually to more stringent criteria as teams mature, and not the other way round.
What happens if we have different DOD criteria across different scrum teams working on the same product?
If the teams within the same organization are working on different products, they can have other DOD criteria. However, if teams are working on the same product, it becomes pretty tricky if they follow different criteria. E.g., we are building an e-commerce product, and Scrum Team 1 is working on Login while Scrum Team 2 is working on My Account Product increment. Team 1 will consider the work done when they have deployed it to the QA environment. However, team 2 will consider it done when they have deployed to the integration environment when other teams can test with it. Such differences in DOD will always lead to confusion. Hence, it’s still best practice to have the same DOD across scrum teams that work on the same product.
