When multiple Scrum Teams are working on one product, shared DoD becomes necessary. DoD helps to ensure that each increment is transparent by the end of every Sprint and creates a shared understanding of what “Done” means. This is what the Scrum Guide says regarding DoD for multiple Scrum Teams:

If there are multiple Scrum Teams working on the system or product release, the development teams on all of the Scrum Teams must mutually define the definition of “Done.”

Recently, I helped launch a group of seven Scrum Teams working on a single product. From their example, I want to show how to create general DoD for a large product group.


Ask What Your Business Wants

Often times, the developers don’t have a hunch that the current state of their engineering practices is not okay for their business. Give the floor to the Product Owner. Let her define the desired level of Done and the desired frequency of releases.

The Product Owner should describe the perfect state that may be quite far away at the moment. For example, she could say: “I want to be able to release 10 times a day.” Record the Product Owner’s wishes on the flipchart and keep this artifact. I call it the Perfect DoD Vision.

The Perfect DoD Vision sets the direction for improvement. The Product Owner should be able to explain the underlying reasons for achieving it.


Make Multiple Variants of DoD

To make the most complete definition of done, ask each team separately to make an exhaustive list of activities and non-functional requirements required to create a releasable increment on a flip-chart.

There is an important reason why you want to create several variants of DoDs that are parallel with all teams. In a mentioned product group, there were 50 people and each team had his own understanding of what done meant. It is more convenient to first create several variants, and then compare and merge them. In facilitation, they call it “cycles of diverge and merge.”

20170831_161030 (1).png

Merge Into One DoD

To merge all DoDs into one, we used the technique called Fishbowl. First, we put all the DoD variants on flipcharts in a row and asked each team to choose a representative. Then the representatives discussed and compiled information from different flipcharts. We wanted to involve as many people as possible, so we did several 10 minute rounds. In each round, we changed the representatives.

Discuss What You’ve Got

The next important step is to discuss the final variant with all of the team members. To make discussion more effective we used stacking: a volunteer read out each item of the DoD, then I asked anyone who wanted to speak to raise the hand . Each person was assigned a number and spoke in numerical order. When the last speaker spoke, I asked if anyone else wanted to speak and started a new stack.


Plan To Remove Technical Debt

After the discussion, we got quite an exhaustive list that provided full transparency of the increment by the end of the Sprint. I asked the teams to put a line on a flip-chart that showed what they are capable of doing right now. Everything below that line was a technical debt that needed to be removed as soon as possible.

So, how do you create general DoD for product groups of more than 30 people? What techniques of facilitation do you use? Please, share your opinion in the comment section.