The Definition of Done tends to be filled with things like;
- All Acceptance Criteria met
- Unit Test Coverage >80%
- No Known Defects
- Peer Code Review Completed
- Documentation Completed
- Integration Testing Passed
Let’s take a look at what the 2020 Scrum Guide describes as the Definition of Done.
Scrum Guide 2020
“The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.”
– Ok.
“The moment a Product Backlog item meets the Definition of Done, an Increment is born.”
– Probably my favorite part here as this supports agility. Shipping valuable product to our customer/user early and often. This is a common message throughout the 2020 Scrum Guide to move people away from treating the Sprint and the Sprint Review as a release cadence requiring approval to release all items completed during the Sprint to production only after the Sprint Review.
“The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.”
– Then there is this that almost contradicts the previous statement and messaging of not treating the Sprint Review as a demo and approval gate. But that is in the nuance of the Sprint Review that gets confused. The Sprint Review is where the Increments that were created during the Sprint can be used and demonstrated for stakeholders and help inform what things we take on in the next Sprint.
I like and dislike the “If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.”
If we build something that meets the Sprint Goal, and this thing was not in it, wouldn’t this be an opportune time to discuss if it was truly needed to support the Product Goal moving forward? I understand the thought process behind this of not showing or discussing incomplete work that was not or could not be provided to our customers/users. But I think this is a missed opportunity, even with Scrum focusing on the stakeholders, to not ask them if that thing that didn’t make it still held the same value as before.
“If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.”
– This could be potentially very dysfunctional. If the organization puts in place a standardized Definition of Done, that requires things so many various criteria that it actively prevents deliverable software, this is a major issue. I have experienced Definitions of Done that were so aggressive that a team was practically strangled by it and we had to make the case that the organizational standard was too restrictive. If the organization is going to create a standard Definition of Done that all teams need to follow at a minimum, please try to make it a minimum Definition of Done, and trust the teams to add to it as needed based on the Product they work on.
“The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.”
– Well this makes sense. There are multiple teams working on a single Product, so a shared Definition of Done makes logical sense. But the teams should be able to discuss and change that Definition of Done as they progress through building product.
Here ends the 2020 Scrum Guide Definition of Done article. Any experiences with the Definition of Done, what you have used, what works, what hasn’t worked, dealing with organizational standards in heavily scrutinized and regulated industries or just start-ups are welcomed to be shared.
Chris Pipito 