Who has the final say to put a PBI DONE ?

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.

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?

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?

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.

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.

 

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.