Definition of Done Workshop

A few months ago I underwent a career change by converting from being a Scrum Master to an Agile Coach. I am still adjusting to my new role but am, by and large, enjoying the challenge and change of pace that it entails. I work with a number of internal teams which represent a fairly broad spectrum of Agile experience from novice to intermediate.

When I engage with a team for the first time I ask them a number of initial questions to help me to gauge their Agile maturity. Some of these concern the Agile ceremonies they practice and the particular Agile artifacts they make use of. What has surprised me so far is that an overwhelming number of these Agile teams did not have a Definition of Done.

For those not familiar with what a Definition of Done (DoD) is I will attempt to summarise the concept here. A DoD is a checklist of useful activities that are carried out by a software team every time they implement a user story. The DoD can, for example, include things like ‘Code’, ‘Unit Test’,  ‘Integration Test’, ‘Peer Review’, etc. The idea is that the culmination of all of these activities against a given set of requirements will result in potentially releasable software. That is quality software that satisfies the requirements. Until all of these activities are completed successfully for a given user story it cannot therefore be considered ‘Done’.

It is important to note that every team’s DoD will almost certainly contain different activities because they do different types of work and have different means of ensuring quality. Therefore every team has to spend some time coming up with their particular DoD.

For Agile teams an agreed and published DoD is essential as it brings transparency to a team’s way of working. Firstly it helps to ensure that everyone on the team is on the same page as to what “Done” means and how they should get there. Secondly as the DoD is written down it can be discussed and subsequently altered as the team agree to make changes to how they work to improve quality and efficiency. For example, via their retrospectives.

Some of the teams I coach had not heard of a DoD. Some had but had not written theirs down. However, they insisted that they knew what it was. As an experiment I asked several members of the same team what they thought their team’s DoD was. I got back as many different answers as the number of team members I asked. Although the teams thought they had a shared idea of their DoD they did not.

As a result of these findings I have been on a DoD offensive of late. This has involved explaining the benefits of having a DoD and helping teams to get their initial DoD published. I have helped so many teams define these recently that I have come up with a workshop format to help drive them out. I present the outline of this DoD Workshop format in this post.

The Workshop Format

The workshop is designed to be run in-person and ideally the entire team should be present. When not all of the team members can attend and the team is not cross-functional then all functions should be represented. No specific preparation is required on the part of the team. I allow an hour for the workshop and hold it in a room with a white board or similar usable wall space.

I start by explaining what the session is about, i.e. creating the team’s DoD which will subsequently be published on their wiki. This of course involves explaining what a DoD is and how it can help the team. This normally raises a few questions from the team and I address these before moving onto the next stage of the workshop.

Next I hand out sticky notes and sharpies. I request that the team think of all of the high-level activities that they normally engage in to get a story done. I ask them to write each of these items onto the sticky notes with one activity featured on each sticky note. I insist that everyone writes up at least a few sticky notes and that they only include the activities that they do now not things they would ideally do in the future.

Once everyone has finished writing I get the team to post all of their items, in no particular arrangement, onto the white board.

Click to Enlarge

Next I ask the team to collaboratively group similar and identical items together. Team members may have used different terminology to describe an otherwise identical activity but by working together they can identify which stickies are actually the same thing.

Click to Enlarge

With the groupings complete we go through each one and validate all of the items within it are truly the same activity. I also check that the team actually does the particular activity now and that it is not simply an aspiration. Any such aspirational items are removed.

Next I work with the team to place each activity group into a timeline. The placement of the activities reflects the order in which each takes place within the team’s development process.

Click to Enlarge

With the timeline in place we now turn attention to creating a headline name for each activity. This is necessary because individual team members may refer to the same activity by a different name. For example, “Implementation”, “Coding” and “Development” are all different terms for the same things. Having the team agree on a single name for each activity introduces a consistent terminology that the team can use to enhance their communication when discussing their DoD. In addition if a team struggle to create a headline name for one of their activity groups then it suggests that it may need to be broken up into several more nameable activities.

The agreed headline names are written against each activity.

Click to Enlarge

With the headline names agreed I go through each activity again. This time I ask the team to define what is involved in accomplishing each of them focusing on the deliverables, outcomes and conditions that represent success. These descriptions are written against each activity beside the headline name.

Click to Enlarge

The combination of the ordered activities and the more detailed descriptions represent the team’s DoD.

Post Workshop

Finally I snap a picture of the board and collaborate with the Scrum Master to have it documented in the team’s wiki and communicated out to the team. If possible I also recommend that a paper copy be posted somewhere in the team’s physical work area.

Note my insistence throughout the process of only including the things the team does now. This may seem overly constraining when the team could be suggesting good adaptions. However, the main purpose of the exercise is to capture what the team does now. Immediately after the DoD is agreed and published the team is free to discuss it and make positive changes. This may even happen in a separate, later section of the workshop. The key is to write it down first, warts and all, so that the team’s improvements can be made against a known state.

When to Run the Workshop

So far I have only used this workshop format to help document the DoD for teams that are already sprinting. However, new teams should not wait until they are partway through a project before they create their DoD. They should instead put it in writing at the very beginning.

I envisage that this workshop format could be used equally as effectively to create the initial DoD for a newly formed team. The only difference would be to have the team write-up stickies for the activities they think they will need based on their previous experience. Otherwise the session could be run in much the same way.

Explore posts in the same categories: Agile, Scrum

Tags: Agile, Definition of Done, Scrum

You can comment below, or link to this permanent URL from your own site.