Skip to main content

Product Owner's approval part of DoD - pros and cons

Last post 03:38 pm July 9, 2022 by Garry Taylor
5 replies
11:10 am July 7, 2022

Hello,

Our team has defined the DoD and one of the condition is to be approved by the Product Owner. If we have this condition In DoD, then the product owner should take over the user stories during the sprint, and not at the end of the sprint - at the sprint review. Some team member think, that If PO does not approve their work during sprint, this will affect on their motivation. What you think about it? Or what are other pros and cons about PO's approval part in DoD.

 

Thank you, beforehand


03:42 pm July 7, 2022

My opinion is that requiring Product Owner approval is an anti-pattern that goes against the Scrum value of Openness and Respect.  If the Product Owner has been able to adequately convey the need and they are being involved in discussions, it seems like a wasted effort to have them "approve".  They should be willing to trust that the Developers will provide the appropriate solution to the need that they have presented.  I feel that stakeholder approval would be more appropriate but even that should not be included in the Definition of Done. 

Remember that the Definition of Done applies to the increment and not to individual Product Backlog Items.  And it is "a formal description of the state of the Increment when it meets the quality measures required for the product." (per Scrum Guide).  If the Definition of Done accurately states the quality measures that all agree to, approval is implied when it meets those standards. The Definition of Done is not an approval stage.  It is a consistent way of communicating. 

Satisfying the Definition of Done creates an increment.  An increment is an usable portion of work that could be released to the stakeholders.  

 


04:37 pm July 7, 2022

Our team has defined the DoD and one of the condition is to be approved by the Product Owner. 

Why? What lead to this? The Product Owner isn't accountable for ensuring that an Increment is Done. The Developers are.

 

 


05:19 pm July 7, 2022

In addition to what others have mentioned, I'll add this. The Sprint Review is not a time and place for approving work, nor should it be the first time the Product Owner is seeing the work and giving feedback. The Sprint Review is a collaborative working session between the Scrum Team and their stakeholders to inspect progress towards the Product Goal, to inspect the latest product Increment to get feedback, and to discuss what's coming next and adapt the Product Backlog.

The Scrum Guide tells us:

The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems.

If a Scrum Team waited until the Sprint Review, might empirical feedback from the Product Owner be too late?


02:10 am July 8, 2022

During Sprint review, Scrum team and stakeholder review what has been done and what to do next



If PO serve as approver for each DoD, Scrum team will be divide into developer and product owner as approver 

While it is good to align internally before showing it to stakeholder but DoD must be determined together as a team 

I don't see any Pro here because approval from PO will become a bottle neck 

btw the most important value of Agile is to collaborate not adding layer of protocol and documentation 

 


03:38 pm July 9, 2022

Something smells bad here.

Developers are not daft and their comments have value. There will be a reason behind the request that must be identified. Shine a light on this request and allow them to be open and honest.

what should happen..

The BPI value has been understood and validated by the product owner. This value has been explained to the team during refinements.

The team forecast that they can complete the work in the sprint. During the sprint, the product owner, QA and shareholders are reviewing item using a CI/CD pipeline.

If there is a mistake, the PO may cancel the Sprint and they will learn from this. AKA maybe getting better requirements and understand of the work they are presenting too the team.

However, at no point is anyone to blame. We learn by failure in most cases, so fail fast.

IMO, asking the PO to signing off work within a Sprint sounds like the team doesn't feel safe.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.