1

Scenario: We have architects that writes specs and acceptance criteria. Business Specialists and Product owner does not give any documented business specs/logic so the architects writes the acceptance criteria and reviews that with the business specialist and product owner in a meeting.

Problem: Whilst the PO was testing the task (Product owner testing mentioned in this post: Post on Product owner testing she found a scenario that does not work. But we have read through the Acceptance criteria and that scenario was never mentioned and she wants to fail the task.

Question: Can a PO fail a task because the scenario was not mentioned in acceptance criteria?

I would say No! because that can cause scope creep.

Issue:

  1. The PO/Business Specialist should write up business logic/Requirements so when a architect works on the spec/Acceptance criteria they can cater for all scenarios.

  2. Don't deviate from the acceptance criteria because they can add all sorts of scenarios or requests after the development.

  • There are no business specialists, architects, or other specialized roles on a Scrum Team. There are only three roles: the Product Owner, the Scrum Master, and the Development Team. If you aren't building cross functional teams that collaborate, you're going to continue to have process issues. – Todd A. Jacobs Mar 12 at 12:30
  • 1
    @ToddA.Jacobs I know, I am a newly appointed scrum master and I am trying to sort out issues one at a time. There are a few issues within the scrum team. – Ruan Mar 12 at 14:29
4

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:

  1. The entire team isn't involved in planning the iteration (including acceptance criteria and the Definition of Done).
  2. 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:

  1. Crafting the current Sprint Goal.
  2. Applying the Definition of Done to Product Backlog Items to identify standard acceptance criteria.
  3. 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.