SSM Supporting Team Events Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Let the discussion continue because root-cause analysis is a valuable retrospective outcome and the team owns the event.

  Why it's wrong here

  Allowing the debate to continue treats a single defect as the retrospective's purpose, which crowds out reflection on the iteration as a whole. The Scrum Master serves the team by keeping the event within its timebox and focused on inspect-and-adapt across the iteration, not by defaulting to one incident. Team ownership of the retrospective does not mean the Scrum Master abandons the responsibility to guide the process.

• ✗

  Cancel the remainder of the retrospective and schedule a separate defect triage meeting so the team can focus entirely on the production issue.

  Why it's wrong here

  Cancelling the retrospective removes the team's only structured opportunity to inspect and adapt the iteration as a whole. A separate triage meeting may be useful later, but it does not replace the retrospective's broader purpose. The Scrum Master should not unilaterally cancel a team event; doing so undermines the cadence and the team's ability to improve how it works together.

• ✓

  Intervene gently, acknowledge the defect topic, and refocus the team on the retrospective's purpose of inspecting the whole iteration before the timebox expires.

  Why this is correct

  The Scrum Master serves the team by facilitating the retrospective and protecting its purpose and timebox. Acknowledging the defect without dismissing it respects the team's concern, while redirecting to the broader iteration inspection keeps the event aligned with its goal. This is a light-touch intervention that preserves self-management and ensures the team still examines all relevant data before the event ends.

• ✗

  Take over the discussion, assign corrective actions to specific team members, and close the defect topic so the team can move on.

  Why it's wrong here

  Taking over and assigning actions shifts the Scrum Master into a command-and-control role that contradicts self-management. The team should generate its own insights and improvement actions; the Scrum Master facilitates rather than dictates. Closing the topic abruptly also risks suppressing the underlying concern, which could resurface and reduce trust in the retrospective as a safe forum for honest reflection.