What Is The Definition of Done In Scrum
Today, I would like to discuss one of the most important aspects of Scrum. However, this aspect is oftentimes neglected by organizations implementing Scrum. And that most important aspect is the Definition of "Done". Neglecting the Definition of "Done" is one of the reasons why we see a lot of failed scrum implementations in the market. Not putting enough emphasis on technical excellence in the Definition of "Done" is one of the reasons why we see a lot of products with technical debt in the market. If I can summarize scrum into a single line statement, it would be to continuously deliver a done increment that achieves the Sprint Goal every single Sprint. So because of these problems we found in the industry, in today's video I'm going to talk about the Definition of "Done" and the importance of "Done" in Scrum. Many of my future videos are going to refer back to today's video, so make sure you don't go anywhere to stay on this video. A lot of people think that the definition of "Done" is the same as Acceptance Criteria.
The Acceptance Criteria is the attribute of the Product Backlog item (PBI) while the Definition of "Done" is the attribute of the increment. Ensuring that the Acceptance Criteria of every Product Backlog item is done, is just one of the checklist in the Definition of "Done". According to Scrum Guide, when the increment meets the definition of "Done", it means the increment is ready to be deployed to the production environment. And of course, ensuring that every Acceptance Criteria is met, is not enough to ensure the increment has production-ready quality. Another checklist that needs to be in the Definition of "Done" to ensure production-ready quality includes all levels of testing such as example unit testing, integration testing, functional testing, penetration testing, security testing, performance testing, etc. A lot of people think that when their organization starts to implement Scrum they no longer need to write any documentation. This is a big fat myth.
In Scrum, any documentation that's written should be valuable both for the business and also for the Scrum team. Any valuable documentation that needs to be written, should be part of the Definition of "Done". So every documentation that is considered valuable both by the business and by the Scrum team such as for example we user guide, troubleshooting guide, release notes, system architecture, test case scenario, etc, should be in the Definition of "Done". Another big fat myth I've found in the market is a lot of people think that Scrum doesn't care about any governance process. Financial institutions that are regulated by the government require the governance process to be done. If the governance process is required for the increment to be considered as done then it should be part of the Definition of "Done". If governance process or audit results either from the government or any international standard body is required for the increment to be considered as production-ready then these items should be in the Definition of "Done". As I said at the beginning of this video, there are a lot of crippling products in the market because the Definition of "Done" does not include any technical excellence practices or any DevOps practices such as for example unit tests script with 90% test coverage, code review through pair programming or mob programming, automated acceptance test script, continuous integration, automated deployment script, automated provisioning script, etc.
During the Sprint Review, only Sprint Backlog items that meet all the checkboxes in the Definition of "Done" that become part of the increment and discussed with the stakeholders. All the Sprint Backlog items that do not meet all the checkboxes in the Definition of "Done" goes back to the Product Backlog for the Product Owner to manage. All the Sprint Backlog items that meet the definition of "Done" can be released to the production environment if the Product Owner wants to. Just like how the Product Owner owns the Product Backlog, the Development Team owns the Definition of "Done" because the Development Team is accountable for the high quality of the product. The Development Team continuously improves the Definition of "Done" usually during Sprint Retrospective to ensure that the quality of the product is continuously improving. So that is all from me today folks. Thanks for watching today's video. I hope you found today's video helpful to help you improve the quality of your product. And most importantly to improve the level of your agility to deliver value to your customers. If you found today's video helpful, don't forget to smash that like button. And also don't forget to share today's video with the world so more people can understand the importance of "Done" in Scrum.