Before We Dive Any Deeper...
You don't have a single problem, you have many. Aside from lacking a cross-functional team that fully collaborates, the two biggest process problems appear to be:
- The entire team isn't involved in planning the iteration (including acceptance criteria and the Definition of Done).
- The Product Owner thinks she's in charge of "testing" or "failing" things, rather than seeing herself as an integrated member of the Scrum Team with responsibility for managing the Product Backlog.
Unless you straighten out both issues, you aren't doing Scrum. More importantly, the Scrum Team will remain dysfunctional so long as the Product Owner and the Development Team remain in contention rather than collaborating closely with one another.
Discovering New Work
The entire Scrum Team (not just the Product Owner) needs to be re-educated about how iterative development really works. In Scrum, each Sprint has a single, coherent goal (the Sprint Goal) that the entire team works on together to complete. Work is prioritized by the Product Owner, selected and planned for the Sprint by the Development Team, and then completed work is demonstrated to stakeholders at the Sprint Review. The Sprint Review can also be a place to discuss why the Sprint Goal wasn't met (if it wasn't), and to gather feedback about the product or discuss next steps and future priorities with stakeholders.
During Sprint Planning, the Scrum Team collaborates on:
- Crafting the current Sprint Goal.
- Applying the Definition of Done to Product Backlog Items to identify standard acceptance criteria.
- Capturing any additional acceptance criteria that might be relevant to particular backlog items that aren't already part of the Definition of Done.
If the Scrum Team did their job during Backlog Refinement and works together properly during Sprint Planning, then there's no place for a Product Owner to "pass" or "fail" work. It simply isn't part of the framework, nor is it an acceptable practice.
What's really happening here is that the Product Owner, stakeholders, or members of the team are discovering new work that wasn't previously identified in Backlog Refinement or Sprint Planning. That's great! What should happen next is that newly discovered work is added to the Product Backlog, so that the Product Owner can refine and prioritize it as future work for some other Sprint.
In iterative development, "scope creep" doesn't happen because newly uncovered work or new requirements can't fundamentally modify the current time boxed iteration. Instead, they become grist for the mill as the product continues to grow incrementally over time.
The sole exception is when something is uncovered that puts the current Sprint Goal at risk. If the Sprint Goal can't be met unless the team goes back to the drawing board, then the Product Owner should declare an Early Termination to the entire Sprint and a return to Sprint Planning. This has a visible cost to the project (visible is good; cost, not so much) so it's generally best to treat new work as future work unless the impact is high enough to justify the cost. That's the Product Owner's decision, and making that decision is a fundamental part of her job.
Beyond that, work is either done or not-done. If it's been done in accordance with the team's plan, completed in accordance with the Definition of Done, and demonstrated within the current time box, then there's no opportunity to "fail" or "reject" the work. The team built the thing that everyone collaborated on and agreed was needed, including the Product Owner.
If it later turns out that the Scrum Team built the wrong thing, then that's a collaboration or communications issue that should be addressed in the Sprint Retrospective. Fixing the process issue will likely involve closer collaboration with non-team stakeholders by both the Product Owner and Development Team members.
On the other hand, if the team simply uncovered new work or the need for additional refinements, then that's great! That's what agile frameworks are supposed to do. The new work can be prioritized and scheduled just like any other work within the framework.
See Also
