I always say the Definition of Done is simple: It is just a common language/ understanding about “What done means” for the Scrum Team and stakeholders.
But why is it very important?
Well! Let’s go through events inside a Sprint and see how DoD supports the Scrum team.
1. At Sprint Planning: Definition of Done helps and guides the Developers to forecast how many Product Backlog Items they can do within this sprint to achieve the sprint goal.
E.g: If your DoD Unit test passed 80%. It means all work: developers need to pass 80% of unit tests, and your development team needs to forecast whether the 5 PBIs they picked can be done following DoD or not. If not, they need to consider picking less work to meet DoD.
2. At Daily Scrum: Definition of Done also guides the team to plan what needs to be done next to deliver a Done increment at the end of the Sprint.
E.g: Back to the last example, DoD of the team is Unit test passed 80%, so the team will review a 24-hour plan of their work following that DOD in Daily Scrum.
- We have done these PBIs with unit tests passed at 80%.
- We still have 3 PBIs to complete; follow DoD for this sprint. Can we still deliver? Any impediments?
- Follow that what is next we need to do? What should be Done (follow DoD) next to achieve a Sprint Goal?
3. At Sprint Review: It supports the Scrum team, and Stakeholders have the same understanding of what Done means. Everybody will review an increment follow that understanding. This will avoid misunderstanding by everybody and no different assumptions about the Done increment.
What happens when the developers think unit tests just need to pass 50%, the PO thinks 80%, and the stakeholder thinks 100%? It will lead to a gap in understanding, and everybody will be easily disappointed because they had the wrong expectation.
DoD is important like that, but many Scrum teams don’t apply DoD or apply it in the wrong way.
What happens if DoD is not applied?
Some years ago, I started a job as a Scrum Master for a media product. At that time, the PO and Stakeholders were very disappointed with the Developers because they could not deliver working software in 6 months. They lost patience day by day.
In the order side, Developers also disappointed as they tried to work hard but still not meet the expectation of PO and Stakeholders
When I came, I figured out that they were missing DoD, so reviving transparency about what Done means is a very important thing I need to do first.
I supported the Developers in defining DoD by themselves. Based on the real situation and their ability at that time.
After that, I asked the Developers to share that DoD with the PO and all Stakeholders so everybody understands what Done means, and at the Sprint review, everybody will review the increment with the same expectation.
Can I copy DoD on the internet or other teams and apply it to my team?
A few years ago, One junior Scrum Master I knew tried to apply DoD to his new Scrum Team. When I asked him how it was going, he shared that he copied a good one from the internet and applied it to his new Scrum team.
What I can say is that you should never do it like that. As DoD should be managed by your Developers, as they know their ability at the time being. Applying the DoD of other mature Scrum teams will put your team under stress, as maybe it’s too hard for them. And they can’t deliver a Done increment with that DoD.
DoD should be created and managed by your Developers anyway, and it will be updated and improved when your Scrum team matures. Please Don’t copy it.
#Scrumantipattents #Scrum #Scrumbut
