What is the Definition of Done?
Definition of Done (DoD)
The goal of Scrum, in simplest terms, is to deliver in each Sprint an Increment that meets the Definition of Done (DoD) and achieves the Sprint Goal. There are many misconceptions about what the DoD means. This is one reason there are many failed Scrum implementations in the market. So, what is the Definition of Done?
What is the Definition of Done?
According to the Scrum Guide, the Definition of Done is a formal description of the state of the software Increment when it satisfies the quality requirements that the product user expects. Think of the DoD as a set of acceptance criteria. When the team has completed the agreed-upon work items, the Increment can be considered complete and ready for release.
Acceptance Criteria and the Definition of Done
Many people think that the Definition of Done and the Acceptance Criteria are the same. They are not. The Acceptance Criteria is an attribute of the Product Backlog item (PBi), whereas the Definition of Done is an attribute of the Increment. Ensuring that every Product Backlog item meets its Acceptance Criteria is just one of the checklist items in the Definition of Done.
According to the Scrum Guide, when an Increment meets the Definition of Done, it signifies that the Increment is ready to be deployed to the production environment. But merely ensuring that the Scrum team has satisfied every acceptance criterion is not enough to ensure the Increment is of production-ready quality.
Why Do We Need a Definition of Done?
Programmers tend to respond optimistically when asked if a feature is “done”. They often say “yes” when they mean only that they have written the code. The functionality may not have been reviewed, tested, or undergone many other necessary quality steps.
Having a DoD avoids a situation where a developer thinks a task is complete when, in fact, it is not. Conversely, it also helps protect against unnecessary perfectionism. Defining “Done” saves time in the long run.
The Definition of Done (DoD) promotes transparency by providing all stakeholders with a shared understanding of the work completed as part of the Increment. You cannot release a Product Backlog item that does not meet the Definition of Done. You should not even show the feature at the Sprint Review. Meeting the DoD ensures quality, reduces rework and increases user satisfaction.
Who Creates the Definition of Done?
If the parent organisation has created a Definition of Done, then, at a minimum, all Scrum teams must follow it. Otherwise, the Scrum Team must create a Definition of Done that is appropriate for the product and adhere to it. When several Scrum Teams are working on a product, they must mutually agree on and comply with the same Definition of Done.
What Should the DoD Contain?
The DoD is a checklist of conditions the completed story must meet to be deemed production worthy. Some examples of the conditions are:
· Unit tests written and passed
· Code reviewed and review comments addressed
· Functional tests passed
· Non-functional requirements met
· Regression tests passed
· Documentation completed
Other checklist items that the DoD can contain to ensure production-ready quality include various levels of testing, such as UI testing, integration testing, penetration testing, security testing, performance testing, etc.
There may be a variety of checklists for user stories, epics, defects, and other deliverables. The DoD checklists are also beneficial in performing upstream activities, like estimation and design.
DoDs: Some Pitfalls to Watch Out For
The DoD checklist should represent the minimum work needed to get an Increment to the Done state. There is no point in obsessing over coming up with a perfect and over-elaborate DoD. The Scrum team should write up the DoD and make it freely available so that all the team members are familiar with it and can access it when needed.
Signs of an Effective DoD
A “good” DoD is one to which the team frequently refers. When asked, they can point you to it. And the DoD actively guides the Scrum team during Sprint Review in accepting or rejecting the Increment. The checklist should be at a high-enough level to make the process repeatable.
DoD and Quality
Not putting sufficient emphasis on technical excellence in the Definition of Done is a significant reason we see many products accumulating technical debt. Consider the DoD to be the formal definition of quality for all releasable artefacts.
Some Common Scrum Myths
Several misconceptions associated with Scrum have a bearing on the DoD, and consequently, product quality.
Myth: Scrum Means No Documentation
Many engineers think that when their organisation follows Scrum, they no longer need to produce any documentation. This is a big fat myth. The Scrum framework only recommends that any documentation created should be of value to the business or the Scrum team. The creation of this documentation should be part of the DoD. These documents could be the user guide, troubleshooting guide, release notes, system architecture, or test plan.
Myth: Scrum is Against Governance
Another myth is that Scrum does not care about any governance process. In reality, all industries regulated by the government must follow a governance process. If compliance with a governance process is required for the Increment to be considered Done, then it should be part of the DoD. Similarly, if audit reports from a certifying body are required for the Increment to be considered production-ready, these items should also be in the DoD.
The DoD is Not Constant
Just like how the Product Owner owns the Product Backlog, the Development Team owns the Definition of Done. They are accountable for the quality of the product. The Development Team continuously updates the Definition of Done, usually during Sprint Retrospectives, to ensure that the process and product are constantly improving.
In Closing
The Definition of Done is an essential concept in Agile. Scrum teams should not even start working on the Product Backlog without finalising the DoD. The DoD should be clear, consistent, and followed by everyone. It should be relevant to the product and enforce engineering best practices. A good DoD helps the team make better plans, estimate more accurately, and execute more effectively and cohesively.