Definition of Done in Scrum: What, Why, and How to Set Up DoD in Your Scrum TeamsThe Definition of Done in Scrum is a gateway that triggers transparency, quality, and consistency in Sprints. All that a team needs is a well-crafted DoD to have more quality increments and satisfied customers.
When we hear about Scrum, we think of self-organizing teams, sprints, incremental deliveries, collaboration, and similar aspects. But there is another word that Scrum teams have to often hear, i.e., Done. For instance, someone asks you: Are you done with the user story? If you say yes, then what exactly does that mean? Therefore, it is important that a team has a clear "Definition of Done", as it can otherwise lead to technical debt, low-quality releases, and other concerns. So, this article is a complete guide for the Definition of Done in Scrum, covering all the basics of DoD and ways to set up the DoD in your Scrum team effectively.
The Definition of Done has different meanings in different scenarios. For Scrum, DoD is defined very well in the Scrum Guide.
According to the Scrum Guide, “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product”. In simple words, DoD is when the increment planned in the Sprint is completed thoroughly and ready for presentation in the Sprint Review meeting.
Every user story in a Sprint must meet the DoD so that the increment goes as planned and delivers the required output. This means that when a user story is moved from "in progress" to "done", it is actually considered completed. However, what defines it as completed is what DoD is for.
The Definition of Done can involve testing, reviews, documentation, quality inspection, compliance, or other factors. It mainly depends on the Scrum team or the organization to set the criteria of DoD.
Scrum Guide also mentions that if one or more user stories don't meet the DoD, they must not be released or presented during Sprint Review. Instead, they must be added back to the product backlog.
In short, a Scrum team must develop a mutually agreed Definition of Done to know when the increment is truly completed and also improve the quality, transparency, and consistency in project management.
The concept of the Definition of Done in Scrum looks confusing. So, let's improve the understanding by considering an example.
Consider that your Scrum team is working on a desktop app project, and the Sprint deadline has arrived. Now, the below checklist will help you reflect on whether DoD is achieved:
1. User Stories Completion:
- All user stories or Sprint backlog items are completed.
- There is no pending user story in the "To Do" or "In Progress" section.
2. Unit Testing:
- The code passes the unit tests and exceeds the predefined threshold.
3. Integration Testing
- Code is integrated into the main codebase.
- Integration tests are completed successfully.
4. Performance Testing
- Performance tests are conducted to check the app's performance with new features.
- User documentation is updated for the new features.
6. Product Owner Approval
- The Product Owner has accepted the user stories.
Based on the above checklist, your team can verify whether the increment is ready to be declared "Done" and submitted for the Sprint Review meeting. This way, a Scrum team can use DoD during every Sprint to ensure transparency and deliver quality increments.
In Scrum, every Sprint or iteration should deliver a valuable product increment. All the efforts in the Sprint should lead to that goal. Therefore, it is important to understand what makes the Sprint worth releasing. This is where "Definition of Done" comes into action. It provides transparency and clarity if the user story is partially or fully complicated. But what can go wrong without DoD?
To better understand the importance of DoD, simply ask your team member: Is the user story done? You will hear responses like it is done, it is completed, it is basically done, all the main aspects are done, etc. Now tell me, do you understand what "done" really means here?
The varying responses are because when you ask someone if the user story is done, the other person can think that you are either asking if the coding is finished or if the coding and testing are completed.
In contrast, if the team knows that the DoD of the user story is complete coding, testing, and integration, they can respond clearly that yes/no the user story is completed.
Another concern of not incorporating DoD in Scrum is increased chances of poor quality increments. Without a proper DoD, there are chances that the user stories might be "nearly done" but not "really done". This partial-finished work can lead to technical debt and less quality releases. However, if the team has defined proper DoD, it is able to pinpoint those nearly done user stories, fix them timely, and lead to proper usable increments.
The Definition of Done has many benefits in Scrum. Some of the key ones include:
- Better Quality: All the user stories go through a proper round of coding, testing, integration, and validation, leading to increased quality increments.
- Effective Team Communication: When the team knows what the word "done" actually means, it leads to effective team communication around the project.
- Enhanced Process Accountability: Every stage of the Sprint is thoroughly checked as per the checklist of the DoD, leading to enhanced process accountability.
- Satisfied Stakeholders: Once a team presents the increments to the stakeholders after fulfilling the "truly done" aspect of every Sprint backlog item, it leads to more satisfied stakeholders.
- Better Performance Evaluation: When the team is actually delivering only completed user stories in every sprint, it makes it easy to determine the Sprint Velocity and performance of the team.
In short, the Definition of Done has significant importance in Scrum. It is a gateway to improve the quality of increments, make progress transparent, and ensure consistency in the development process.
Now that we know the necessity and benefits of the Definition of Done in Agile Scrum, the next question is how to set up DoD within a Scrum team.
There are no standardized steps or checklists of DoD that Scrum teams can follow. It basically depends from team to team, just like the team is free to estimate product backlog items using any estimation technique of their choice, like Planning Poker, Async Poker, Dot Voting, etc.
So, what your Scrum team can do is sit together and create a mutually agreed DoD. Below are the general steps that are useful in establishing DoD for the first time:
1. Arrange a meeting where the whole development team participates.
2. Allow everyone to name the items that should be part of the DoD checklist. The items can be:
The team can use sticky notes and the whiteboard to arrange the points for better understanding.
3. Once the items are shortlisted, add the sub-items within each item. For the above items, the sub-items can be:
- Coding - Functional, comments
- Review - Bugs, UX design, acceptance criteria
- Testing - Unit testing, integration testing
- Approval - Product Owner approval
- Documentation - Developer, support team
- Compliance - Security, legal
4. After finalizing the items and sub-items, the team has created its DoD. Now, the team should communicate the DoD with the key stakeholders. Afterward, the team should test the DoD in the upcoming Sprints and adjust the checklist according to the situation.
This way, your Scrum team can easily create DoD in a mutually agreed way.
Please note that the above items included in the DoD checklist are just for reference. The DoD can vary based on the project requirements. Therefore, your team must consider the project needs and structure the DoD accordingly.
However, it is not mandatory for the Scrum team to establish the DoD on its own. According to the Scrum Guide, if the DoD of the increment is mentioned in the organization standards, then the Scrum team must follow it. Otherwise, the Scrum team is free to set up DoD depending on the project requirements.
Definition of Done defines the quality standards of the increment in the Scrum. A well-structured DoD brings transparency, quality, and consistency to the development process. It makes evaluating the team's performance and shortcomings easy, resulting in more productivity and satisfied stakeholders. Therefore, we will wrap up the article by recommending you establish DoD with your Scrum team and conduct more fruitful Sprints.