Acceptance Testing Isn't the Product Owner's Role
It's a good thing that you have a Product Owner that wants to be involved in Product Development and the QA/UAT process. However, while collaboration is great, testing is not part of the Product Owner role in Scrum.
The Scrum Guide says:
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
What your Product Owner is doing is not intrinsically doing any of these things, and isn't leveraging framework processes and practices to ensure quality.
What to Do Instead
The Product Owner should certainly collaborate with the Development Team. This includes helping the Scrum Team craft the Definition of Done, set Sprint Goals, and participate in Sprint Reviews and Retrospectives. However, the Product Owner's focus is on defining the work and optimizing value, not performing QA or acceptance tests.
As a Product Owner, especially when part of an immature Scrum Team, I may ask the Development Team to demo critical features that meet the Definition of Done throughout the Sprint rather than waiting until the very end. Or, I may ask them to do a "prep demo" within the team ahead of the formal Sprint Review in order to make sure we're all on the same page.
As the Product Owner, I don't get to approve the work. Instead, I work through the Product Backlog to define work, and through the Definition of Done to set expectations about quality. Most importantly, I work through the Sprint Goal to set expectations about what qualifies as a delivered or non-delivered increment of work.
If my Sprint Goal has been met in accordance with the Definition of Done, then the work increment has been successfully delivered. If the Sprint Goal has not been met, then the work increment has not been successfully delivered. That doesn't mean work hasn't been done, or that various bits of work haven't been done properly; it just means that the iteration has not achieved the scope and value planned for it.
As the Scrum Master, part of your job is to educate the Product Owner on the responsibilities of the role. Help the Product Owner use the tools of the framework properly, and to collaborate effectively with the team.
If the Product Owner is routinely testing the product or its features through each Sprint, this may be an indication that the Product Owner perceives an ongoing quality issue or lacks trust in the Development Team. This is an opportunity to improve communications, re-evaluate the Definition of Done, or otherwise inspect-and-adapt the process to increase trust between the key team roles.
Likewise, if the Product Owner is routinely providing feedback at the implementation level (rather than at the system or feature level) within the Sprint, this is a framework implementation smell that may indicate poor Backlog Refinement, poor Sprint Goals, user stories that lack adequate context, or user stories that don't meet INVEST criteria. If that's the case, then working with the Product Owner and the Development Team to improve the contents of the Product and Sprint Backlogs, and to improve adherence to the INVEST criteria (especially the Testable requirement), will often yield significant process improvement.
In addition, non-developer inspection of an increment other than at framework inflection points can also lead to scope creep. For example, if the Product Owner is inspecting a feature that meets the Definition of Done but requests in-Sprint changes, this may represent a change of scope or design that wasn't part of the current iteration's Sprint Planning. Developers should actively collaborate with the Product Owner to define scope and design issues, but any feedback that changes scope or puts the Sprint Goal at risk needs to be carefully negotiated. An obsolete Sprint Goal, or significant changes in scope, may necessitate cancelling the Sprint and returning to Sprint Planning.
In each of these examples, the Scrum Master's key objective is to help the entire Scrum Team build confidence and trust. This means:
- The Product Owner needs to be confident that the Development Team's process will successfully deliver the Sprint Goal.
- The Development Team needs to be confident that they're being given a clear problem with adequate context, and that the information is sufficient to identify and implement a solution within a single iteration.
- The Development Team needs elbow room to find the simplest design and implementation that will meet the Sprint Goal.
Your goal as the Scrum Master is facilitate trust, which is built through visibility, transparency, and open communications. Leverage the Sprint Retrospective and other framework elements as much as possible, but always ensure that you are solving for any real underlying trust and communications issues, rather than just addressing the symptoms.