Answering: “In an environment where user acceptance testing is required before the Increment can be put into production, a development manager proposes to have user acceptance testing done every third Sprint because the feedback from the user acceptance tests is disrupting work in Sprints. Is this a good idea?”

No. Running user acceptance testing only every third Sprint makes the Increment less transparent and stretches the feedback loop. If UAT is required for release, it belongs in the Definition of Done.

Exam Question

In an environment where user acceptance testing is required before the Increment can be put into production, a development manager proposes to have user acceptance testing done every third Sprint because the feedback from the user acceptance tests is disrupting work in Sprints. Is this a good idea? (choose the best answer)

• A. No, the Increment will not be transparent and the feedback loop is too long.
• B. It depends on what is stated in their Definition of Done.
• C. Yes, the Scrum Team is a self-managing team.
• D. Yes, the Scrum Team needs stability in the Sprint.

Correct Answer

A. No, the Increment will not be transparent and the feedback loop is too long.

Why This Is the Correct Answer

If user acceptance testing is required before release, then an Increment without it is not truly releasable. Pushing that testing to every third Sprint means two of every three Increments hide an unknown amount of remaining work. Problems found later are bigger and costlier to fix. The Scrum Guide says the Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. The better fix for disruption is to include UAT feedback in the normal flow, for example by bringing users closer to the team, automating tests or adding UAT to the Definition of Done.

Why the Other Options Are Wrong

B. It depends on the Definition of Done. If UAT is required for production, leaving it out of the Definition of Done is itself the problem. The answer does not really depend on it.

C. Yes, the team is self-managing. Self-management does not justify hiding undone work or reducing transparency. The proposal also comes from a manager, not the team.

D. Yes, the team needs stability in the Sprint. Stability is not a reason to delay feedback. Late feedback causes bigger disruptions later.

Exam Tip

When a proposal batches testing or integration across Sprints, the answer is almost always no. Scrum prefers short feedback loops and Done Increments every Sprint.

Key Takeaways

• Required release activities belong in the Definition of Done.
• Delaying testing hides undone work.
• Short feedback loops reduce risk and cost.