PO and DoD
Hi everyone, so I am studying (still) to pass the PSM I.
This question came up in an external website (recommended in this forum);
The Product Owner has doubts about the quality of the definition of “Done”. What should s/he do?
Answer: Increase the product quality by adaptation of the definition of done in the next sprint retrospective.
I got the answer correct, but at the same time I have doubts/ confusion.
So in the scrum guide it says:
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.
If the dev team defines the DoD, how can the PO adapt the DoD?
I think I understand that the PO can influence the quality, but I thought that would be done more with items in the Product Backlog and order/importance.
Can someone help me understand a bit better this?
Thanks
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.