Skip to main content

Who has the final say to put a PBI DONE ?

Last post 03:48 pm March 22, 2024 by Daniel Wilhite
6 replies
07:54 am January 24, 2024


Recently, I had a thought-provoking conversation as a Scrum Master with the Product Owner PO regarding the DoD and its impact on the Jira workflow. The discussion revolves around whether the PO should have the final say on whether a PBI is done or not.


1. PO Opinion:
He argues that every PBI should undergo final validation by him to ensure it meets the acceptance criteria and provides value to the product.

2. My opinion as a Scrum Master:
My concern is that making the PO the final arbiter could potentially create bottlenecks in the workflow. The DoD, in my opinion, is a commitment by the Developers for the Increment, much like the Sprint Goal is the commitment by the Developers for the Sprint Backlog and the Product Goal is the commitment by the Product Owner for the Product Backlog.

What do you think ?

07:37 pm January 24, 2024

I would be curious why the Product Owner wants to do a "final validation" of every Product Backlog Item. To me, this would likely indicate that the Product Owner doesn't have confidence in the team to build what is desired and needed, and I'd want to dig into that, especially with respect to refinement, Sprint Planning, and the interactions between the Developers and the Product Owner during the Sprint.

If the Product Owner understands the implications of becoming a bottleneck in the workflow, then they should also realize that this would negatively impact the team's ability to quickly deliver value to stakeholders. The Product Owner has accountability to maximize the value delivered by the team, and this doesn't seem to accomplish that.

08:28 pm January 24, 2024

The discussion revolves around whether the PO should have the final say on whether a PBI is done or not.

The Scrum Guide makes it clear that the Developers are always accountable for instilling quality by adhering to a Definition of Done.

Have you discussed whether the PO trusts the Developers with this accountability, and if not, why not?

11:16 pm January 25, 2024

In this conversation, are Acceptance Criteria and DoD being confused? If the PO is wanting to see the results of the acceptance criteria for a PBI wouldn't that be something that the PO and Developers are already reviewing together and aligning that the work meets the AC?

09:29 am January 27, 2024

This type of questions I always look at the perspective from a scalability point of view.

If a team feels an additional pair of eyes is needed to get to Done for whatever reason, why not. It might be because of a skill the Developers are currently still missing.

If the PO has to be that pair of eyes, what happens if this PO has 1 team...? What happens if this PO has 10 teams...? What happens if this PO has 50 teams...?

Needing an additional validation from outside the Developers shows a missing skill. As long as the Developers do not have this skill, ask for this validation to have confidence in the quality. Meanwhile the team should work to grow this skill.
If the PO has to do this work, then it is not scalable. Maybe this level of scalability is not needed. Maybe the Developers will grow the skill fast enough so by the moment the scalability issue pops-up the Developers cover the needed skills.


04:09 pm March 21, 2024

This issue has emerged within a project I have worked on, and I'd like to share my perspective on it. I also want to acknowledge and support the comments and experiences contributed by others in this chain; it seems we're all aligned in our approach.

While the Scrum Guide doesn't explicitly outline who should carry out certain actions, it does mention that the Development Team is responsible for crafting the Sprint Backlog during the Sprint. Unfinished items at the end of the Sprint, are then moved to the Product Backlog, as highlighted in our discussions. Now, once a Product Backlog Item (PBI) is finalized, it must adhere to the Acceptance Criteria (AC) and the Definition of Done (DoD) to transform it into a probable shippable Increment to production. When a PBI evolves into an increment, it signifies that both the AC and DoD have been met, fostering transparency for the Product Owner (PO) regarding the readiness of the increment for production deployment.

I share the sentiment expressed about the QA team's need for additional skills, particularly in conducting functional tests. This could be a temporary measure until a consensus is reached within the Scrum Team (during Retrospective meetings). However, the QA team must commit to becoming a cross-functional entity. Additionally, I've noticed that when the responsibility for QA is shifted to the PO, members of the QA team might become complacent, assuming that someone else will ultimately approve the PBI. This can result in inadequate testing of functional, regression, and integration testing aspects. They might say "Somebody else will do QA on behalf of my activity and will become the final approver."

In the Scrum Team I've collaborated with, the Scrum Team agreed, that the Development Team transitions PBIs to the "DONE" state, effectively transforming them into increments ready for production deployment. However, a flag indicating readiness (true or false) is attached to each increment, allowing the PO to later determine with stakeholders whether to enable its deployment in a productive environment.

Requiring the PO to approve each PBI individually could create a bottleneck and contradict Lean principles. While it ensures that no PBI is approved without meeting AC and DoD, it might not foster transparency.  

All these comments do not leave aside the PO's responsibility to know what is finalized during the Sprint, so that this situation defines the guidelines for developing a Review Scrum ceremony.

To resume, I consider that each Scrum Team should establish its own workflow process based on its maturity and possibilities, incorporating automated QA processes such as Continuous Integration/Continuous Deployment (CI/CD) pipelines. There's no one-size-fits-all solution for every context situation.


03:48 pm March 22, 2024

Now, once a Product Backlog Item (PBI) is finalized, it must adhere to the Acceptance Criteria (AC) and the Definition of Done (DoD) to transform it into a probable shippable Increment to production. 

Respectfully, you are confusing user story practices with Scrum principles.  Acceptance Criteria is not mentioned anywhere in the Scrum Guide.  They are a practice that evolved in places where people use User Stories to define their Product Backlog Items.  In fact, Acceptance Criteria were not part of the original User Story format. 

The Scrum Guide states this in the section where it describes the Sprint Backlog under the subsection for the "committment". 

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

The Definition of Done does just that. It defines what it means to be "done" with a Sprint Backlog item.  How and what is contained in that definition is entirely up to the Scrum Team unless there is an organizational standard in place.  Then they may add additional defining characteristics but they must adhere to the organizational standard. 

If a Scrum Team decides that there needs to be some type of "Product Owner signoff" in the Definition of Done, none of us can say they are wrong. But in all organizations where I have seen that as part of the definition, they realized it to be a gating activity and it was removed from the definition.  If the Product Owner is not involved in the work that is being done enough to realize that it is being done to satisfy the request, then THAT is the impediment that needs to be discussed and addressed.

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.