PO and DoD

The Scrum Guide says: “During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of "Done", if appropriate and not in conflict with product or organizational standards.”

Hence the Product Owner, as a Scrum Team member, can help to adapt the Definition of Done.

The Product Owner’s ultimate sanction over product quality lies in his or her authority to release.

If the Product Owner has any doubts about quality then, in order to avoid waste, he or she ought to raise the concern immediately with the Development Team, and not wait until the Sprint Retrospective.

Ok, so the Dev team can DEFINE the DoD, and the Scrum Team can ADAPT the DoD as more is know etc.

In your experience though, is the PO involved/influence in Defining the DoD?

Thanks

The PO could be involved, because the DoD has to be appropriate for the product. Then again, he or she may be happy to leave the matter to the Development Team. Scrum is only minimally prescriptive.

@Mike - I have had some of the same questions as you in terms of putting the Guide into practice.

In my experience, the practical development/evolution of the DoD depends a lot on the maturity of the team members and the degree of understanding each has of the product and its intended use/market.

The development team is expected to have both the know-how (technically) and the pride (as professionals) to establish the DoD as a quality standard for the product they're building. With mature teams, this usually happens more naturally.

The piece that most commonly needs the PO's involvement is helping the developers understand (in the words of the Guide) what DoD is "appropriate for the product."

What I've seen at times is new teams struggling with this portion. Sometimes they set the bar too high, thinking that "more is always better," but making the standard so onerous that it starts reducing value. (Simple example, if overzealous developers created a DoD that included numerous code reviews, it might be excessive.) This is where the PO might need to step in and say, "Hey team, I love your commitment to quality, but I don't see the value-add in all these reviews. Right now the cost of delay is pretty high so what if we adapt our DoD to remove some of the extra reviews and observe whether quality actually suffers?"

Likewise, I've seen teams (again, usually a team of folks new to Scrum and new to owning product quality) get a little lazy with a DoD. They might have one or two items on a DoD checklist, but are still leaving out some important steps. The Scrum Master can of course kick them in the seat of the pants, emphasize the importance of quality and the like, but sometimes the PO can make the point better by (continually) helping the development team see how the DoD actually impacts the usability, marketability, popularity, etc., of the product as it's being released. For example, the PO is often the first person on the team who receives negative feedback from users related to product quality. If they bring that to the team's attention (with the right approach/attitude, I'll add!), this sort of real-life scenario may be what's needed to help the team adapt the DoD appropriately.