Use the Definition of Done Canvas as a template to help you and your team create an effective Definition of Done.
In Scrum, the output of every Sprint is a Product Increment. This Product Increment should be of high enough quality to be potentially shippable should the Product Owner so see fit. Many teams struggle with delivering a Product Increment at the end of a Sprint, let alone a high quality Product Increment that is ready to be shipped. Check out this blog post series for more on this problem and how the Definition of Done might help improve your team’s technical excellence.
To use the Definition of Done canvas, start out by asking the team what are all the activities that are needed to take all the code that is setting on a developer’s machine and get into production or ship it to the end customer. What environments are needed? What kind of testing is required? What kind of approvals? Have them write down 1 activity per post it.
Next, ask the team which activities can be completed per Product Backlog Item. That is, when a user story is moved from the in progress column to the done column, which activities from this list can get completed. Move those activites to the PBI section.
Next, ask the team which remaining activities are too expensive to do per Product Backlog Item, or too time consuming, or too resource intensive to do per Product Backlog Item, and instead, need to be done just once per Sprint towards the end. Move those activities to the Sprint section.
Next, ask the team which activities are too expensive to do per Sprint, or too time consuming, or too resource intensive to do per Sprint, and instead, need to be done once after several Sprints right before we ship. Move those activities to the Undone Work section.
Next, ask the team which activity from the Undone work section are they going to improve on next and try to include as part of the Sprint. Copy that activity into the Undone work improve on box.
Finally, ask the team which activity from the Sprint section are they going to improve on next and try to include as part of each PBI. Copy that activity into the Sprint improve on box.
This list is the team’s Definition of Done. It is transparent, clear, and grounded in reality based on the team’s context and environment. When someone says, “I am Done”, everyone understands what “Done” means and which quality activities have been completed and what remains to be done in order to deliver a quality product.
If a team’s current Definition of Done includes activities in the Undone section, then this team, based on their current environment and constraints, cannot deliver a shippable Product Increment at the end of every Sprint because there are additional quality tasks and activities that still need to be completed. This means that if the Product Owner is satisfied with the output of the Sprint, it is going to take another 2 weeks or 2 months to get the Product Increment shipped and delivered, depending on how long the activities in the Undone work section take.
And that’s OK as long as the Definition of Done is transparent and everyone is on the same page. However, the Definition of Done is not static. The team is grounded by their current reality and constraints, yet they must continuously improve.
Every couple of retrospectives or so, the team needs to pull up their Definition of Done and figure out how to improve on it by pulling items from the bottom Undone section and try to move them up so that they are included within the Sprint. They also improve by trying to move items in the Sprint section and move them up to be included per PBI. This is done gradually by identifying which activity the team is getting better at and placing it in the improve upon box of the canvas. The team tackles these one at a time until there are no longer any activities left in the Undone work section.
Once that is the case, then we have a high functioning Scrum team that can actually deliver shippable Product Increments at the end of each and every Sprint.
Now there are other teams that go even a step further and try to push everything into the Product Backlog Item section and have nothing left in the Sprint section and the Undone work section. Those teams are capable of shipping multiple times per Sprint or even multiple times per day. If teams get that far great! However, at a minimum Scrum teams have to get to having nothing in the Undone work section and have all the quality activities completed by the end of the Sprint. Obviously, this won’t happen overnight. It will take time, but via the continuous improvement of the Definition of Done and improvements in the team’s technical practices, teams tackle these and get there one step at a time.