At Hard Yards we work with a range of clients and teams across several organizations, helping them in their journey towards Agile. One of the most important things a team can do when starting working together is create a shared Definition of Done. Yet, we rarely see this happen, or rarely see this formalized in a useful way. Here is a brief guide on how to create one.
What is a definition of done?
Chances are you encounter the Definition of Done in your everyday life without even thinking about it. Consider what it means to “Clean the house”, “Make Dinner” or “Complete a Workout” Those activities have vastly different definitions of “done” depending on who you ask. Your Agile team is no different. “Done” likely means different things to different people on your team, so taking the time to get aligned can save the team a lot of headaches, giving them a common place from which to start.
The goal of a team is to produce working product increments at the end of each Sprint. The work for each increment should be completed so that the increment can be demoed to stakeholders, validated with customers, or released to production when needed. How do you know when your work is completed, how do you know when you are “done”?
The Definition of Done is a list of criteria that the team identifies as required for any piece of work to be considered “done”. Only when the work product satisfies all the criteria can it be considered complete. At the end of each Sprint, all work should be evaluated against the Definition of Done. Any work that is not “done”, is not completed, and therefore goes back into the backlog.
How is the Definition of Done different from Acceptance Criteria?
While the two terms are often confused, a simple rule of thumb is the Definition of Done applies to (almost) all work items, whereas Acceptance Criteria may be unique to just one. This graphic helps differentiate between the two
Teams may define “Done” at different levels
Whether we are describing “done” for an individual user story, an increment or an epic, the same boundaries hold true. The Definition of Done at each level should apply to all. What defines done for one increment should define done for the next increment. In that way, we build standards of quality from the individual team level up. Next, we’ll take a look at how to create a definition of done at the story level, but the same practice can apply at any level.
How to create a Definition of Done at the Story level
Here is a simple yet effective way to create an initial Definition of Done with your team. This is a team exercise and easily done using collaborative tools online, or in person. The important thing is to make is a whole-team effort. This exercise should be facilitated by your Scrum Master (or an Agile coach).
STEP 1: GATHER INSIGHTS
Everyone spends a few minutes thinking of what needs to be true for the work product to be completed. This is a solo exercise. Write each idea or item on a post-it. Things such as “code complete,” “automated test cases written,” “peer review complete” are common in software development environments, but your team will likely come up with a range of things that describe their own work.
STEP 2: AGGREGATE INSIGHTS
One by one, each team member shares with the rest of the team their post-it and places them on the virtual (or in-person) whiteboard. While doing this, look for common topics and similar ideas, and group them together to create clusters of post-its.
STEP 3: DOT VOTING
Each team member puts a green dot or a red dot next to each topic identified. A green dot means that the team member supports that idea. A red dot means the opposite, the idea is not needed, seems redundant, or has no merit.
STEP 4: SYNTHESIS
When everyone has finished voting, remove all the stickies that received red dots. You should leave only those that received green dots – no one had any concerns with these. These topics create your first Definition of Done.
Once your team has created its Definition of Done, write it down in a document, and make the document easily accessible to everyone. For the first couple of sprints after creating it, the Scrum Master or Coach can remind the team of the Definition of Done. It can be used as the standard in the Sprint Review as well, to determine if a story was complete..
Creating your first Definition of Done is a great step, but the work doesn’t end there. The Definition of Done should be treated as a living document. It should be reviewed, assessed, and updated as frequently as necessary, especially early on. For example, if during Sprint Review or Retrospective the team discovers that something is missing in its Definition of Done, the team can review and update the document. At times, the technology changes, or the organization’s requirements change (say, the organization pushes for a new type of encryption for all teams). That’s also a great time to review and update the Definition of Done.
Read more about how Hard Yards can help you with your work.