Skip to main content

How to Create DoD for a Large Product Group

October 8, 2017

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.

B3.png

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.

В.png

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.

20170901_092608.jpg
 

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.


What did you think about this post?

Comments (19)


Alan Larimer
05:16 pm October 9, 2017

Why is the Product Owner directing the "Perfect DoD Vision" without input from the Development Team and Scrum Master?

"I want to be able to release 10 times a day" is a great statement related to process, highlighting a desire for continuous delivery, but how does that relate to the purpose of the DoD? "a shared understanding of what it means for work to be complete" (The Scrum Guide)

The conglomeration of Scrum Teams should be asking how they can decouple the monolithic application into multiple products to reduce complexities: dependencies, coordination, etc.


Илья
04:45 am October 16, 2017

Alan, exactly so ) The PO sets the DoD she would like to have ("10 times per day") and then DT finds ways (input) to accomplish that. I would be surprised to have it the opposite way. So yeah, the whole Scrum Team is involved.


sami hadhri
10:04 am October 16, 2017

Much Better than the concept of "Corporate DoD" I've seen in some companies !!


Alan Larimer
02:20 pm October 17, 2017

For some reason, my reply is not appearing. Therefore I am posting it again.

Please cite The Scrum Guide supporting your position. https://scrumguides.org/ A citation against being "surprised to have it the opposite way": "If 'done' for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of 'done' appropriate for the product."

Having the Product Owner define the Definition of Done "then DT finds ways (input) to accomplish that" sounds more like classic, top-down, command and control project management than a collaborative team.

My previous quote questions "release 10 times per day" even being a factor in the Definition of Done.


Илья
09:27 am October 18, 2017

Let me clarify some points from the article. Please let me know if that makes sense for you.
When PO said that she wanted to "release 10 times per day" that was a shock for the DTs because their current level of engineering practices was quite far away from that. On the other hand, PO saw her market as rather volatile and wanted to speed up the release cycle. DTs realised they had to evolve their common DoD over time to support business.


Alan Larimer
02:56 am October 20, 2017

I absolutely agree that expressing business needs, such as market volatility, is extremely valuable and should be used to prioritize process and practice improvements. I still disagree with the premise of having the Product Owner define the Definition of Done "then DT finds
ways (input) to accomplish that" and that release capabilities relate to the Definition of Done. You continue to fail to support your argument with citation.


Alan Larimer
12:51 pm November 6, 2017

It's not a matter of who should "go first" when creating the Definition of "Done" as that is exemplifying the issue. Having the Product Owner define the Definition of Done "then DT finds ways (input) to accomplish that" is traditional hierarchical management and not collaborative as it should be. Together the Scrum Team should create and later expand the DoD. The Development Team provides technical aspects that are possible; the Product Owner provides business and customer desires; the Scrum Master provides suggestions for other possible aspects. Or you could follow The Scrum Guide: "If 'done' for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of 'done' appropriate for the product."


Alan Larimer
03:46 pm November 18, 2017

@rob_pointer:disqus

A response to my points would be appreciated.


Alan Larimer
03:49 pm November 18, 2017

@andris9 @aza9999 @emily_condit @itiswhatitisnt
Please explain your votes. I have supported my position with citations from The Scrum Guide while he has not. Why does the Product Owner drive the Definition of "Done"? How does this fit into the definition for the DoD? How is "DT finds ways (input) to accomplish that" not traditional command-and-control management and against the Scrum framework idea of a collaborative Scrum Team?


Илья
07:01 pm November 18, 2017

Alan, just a few thoughts

From section Uses of Scrum:
"Release products and enhancements, as frequently as many times per day;"

Sentense from DoD section:
"Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it."
"If "Done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team MUST define a definition of "Done" appropriate for the PRODUCT."

Say the Product Owner sees value in releasing software every day. This is quite frequent situation I see working with my clients. The market is volatile and PO wants to get feedback as fast as possible. PO would like the Development Team to develop new capabilities for that. She's ready to invest in learning and upgrading DT skills.

I have a few questions for you:

Do you find it reasonable for the Development Team to say "oh, no... sorry, we don't care... you see right now our development level doesn't allow to do that, sorry. And we don't want to learn"? How does that relate to Scrum Values?
Who has budget and responsible for ROI in Scrum Team?
Does the Development Team "hire" the Product Owner or the other way round?
Who is capable of adding/removing Development Teams working on the product?

And yes, the Scrum Team creates DoD collaboratively.


Илья
05:53 pm November 23, 2017

Somehow I see the new replies in my inbox Gmail, but cannot directly respond when get back here. Just a bit lost (my bad) and want to get back to the core of the article. I believe you all want to improve the article, so please help me. Again, main points:

1) product group wanted to create a shared DoD
2) we started from defining perfect definition of done (PDoD). PO would love to release every day, in this case it meant making current DoD stronger. Development Teams agreed on helping achieve this goal.
3) First they we created 7 different PDoDs in separate Teams (diverge phase).
4) Merged them using Fishbowl technique
5) Agreed on current DoD
6) Planned steps to move closer to PDoD.

Please let me know if that doesn't make sense.


Alan Larimer
05:12 pm January 30, 2018

A response, since posting it here has been repeatedly prevented: https://www.linkedin.com/pu...


Another Life
05:19 pm January 30, 2018

No response?


Another Life
06:16 pm January 30, 2018

It's an interesting exercise for developing a DoD. However, I agree with @alanlarimer:disqus on several points. Release frequency has nothing to do with the value in the DoD. The phrase regarding the PO setting the standards and the DT having to find a away to make it happen is inconsistent with Scrum and agile values.


Alan Larimer
01:50 pm February 7, 2018

It happens. I haven't reviewed email notifications settings through Disqus recently, but I also regularly connect. I enjoy discussion and, as they say, late is better than never but that choice is up to you.


Alan Larimer
01:58 pm February 7, 2018

Can you please elaborate? I've experienced "Corporate DoD" that matches traditional, Taylor, PMI thinking and wouldn't want to misunderstand if we had different ideas of that phrase. " If the definition of 'Done' for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must
follow it as a minimum." I believe that this along with other parts of The Scrum Guide are big contributors to ScrumBut/Somegile/ScrumWaterFail.


Alan Larimer
02:00 pm February 7, 2018

Looks like replies can generate emails, but mentions might only trigger web notifications.


sami hadhri
03:12 pm February 7, 2018

Exactly, it's a DoD set by Quality department for all teams in the company. It's a minimum DoD to meet by all the teams in the company.
As a consequence, teams do not necessarly adhere to this DoD and they dont feel responsible on meeting it.


Alan Larimer
03:30 pm February 7, 2018

Having a separate "Quality department" would be an anti-pattern. Development Teams that do not own quality is a maturity issue. So it would depend on the context of what those universal standards are. Arbitrary metrics (i.e. at least 7 unit tests, 4 integration tests, and 5 end-to-end tests) could be standard corporate good intent but poor implementation. Something such as prohibiting any known critical severity defects could be valuable.