This is often a dreaded part of running a Scrum (or any) project, but it doesn’t have to be. So here's the quick-n-easy on creating your Definition of Done.
It was once odd to me that we need to define this. However, lessons learned from my projects have impressed upon me that what I think is done may not/is not the same as the Development Team, Product Owner, Stakeholders, nor perhaps, the Sponsor (the big cheese 🧀). That said, this is a crucial step to ensure the completeness of the final product. It only takes one misunderstanding before you, too, will see its importance.
💡 Each team member may have a different understanding of “work completed” for the team’s deliverables. [A Scrum Book]
Ryan’s (that me) Definition of Done (DoD): The agreed-upon state (via the entire Scrum Team) of a Backlog item that does not require any more work to be finished.
There is nothing worse than asking someone if they finished tasks (be it in a project or life) for them to tell you yes. Only to find out a moment or several hours later that they didn’t finish it. “Oh, well, yes, I finished that part, but we still need to wait for that other part for it to “really” be done…”
Let’s have some discussion on what DoD is and isn’t. You can get the official work on DoD via the 2020 Scrum Guide.
The DoD is a formal description of the state of the increment when it meets the quality measures required for the product. For the sake of all trying to understand this (trust me, I get it), an increment is a slice of time. In our specific case concerning a project, an increment is better defined as a slice of time that holds all completed tasks from the current and previous sprints.¹
When used as intended, the DoD creates transparency throughout the Scrum Team by providing a shared understanding of what work was completed as part of the Increment (recall, only fully completed tasks, meeting the DoD, are part of an Increment). If a Product Backlog item does not meet the DoD, it cannot be released nor presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration or yet-to-be-finished work.
If the Definition of Done for an Increment is part of the organization’s standards, all Scrum Teams must follow it as a minimum. If it is not “the standard,” the Scrum Team must create a project-specific DoD considered appropriate for the product. When working in an organization with either one or five (or more) project/Scrum teams working in tandem, I highly recommend coming to the table with a universal DoD for teams to build off. This will ensure all players are following the rules.
Also, your Scrum Master, while giving the team their autonomy, will need to ensure the Development Teams are finishing work that conforms to the DoD. If the team cannot meet the standards, there may be a reason. Are the standards unachievable, or is the team not flowing?
Create your Definition of Done
You can create your own DoD any way you want. Seriously. Got a napkin near you? Write down what you consider done to be for this Sprint’s tasks. However, I recommend using a checklist. This allows you to literally go down the list to see if the “completed” tasks meet your definition. Here’s an example-
Meta-physical-not-real World Creation DoD Checklist
- Acceptance criteria are verified during testing
- Code creation tasks completed
- Testing completed and signed
- Regression testing has been reviewed and passed
- Code reviews conducted
- Defects are in an “acceptable” state to the Product Owner
- User story accepted by the product owner
- Regression tests run and passed
- Automated unit tests are checked in
Your list may only have a few (three to four) items, which would be better than my fake list above. The team should know what these are (perhaps print them out, or put them up on screen during remote meetings) to ensure they’re meeting the mark as they’re working on their tasks.
That’s it. Not much to it.
Have a question on this or other topics of Project Management? Let's chat, I love getting your emails.
Previous articles in this series: