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.

• ✗

  Ask the Product Owner to attend and prioritize the improvement items so the team can focus on the highest-value actions.

  Why it's wrong here

  The Product Owner prioritizes product backlog items, not team process improvements. Involving the Product Owner in the retrospective can also inhibit open discussion, as team members may temper their comments about process or collaboration. The retrospective is a team event, and improvement actions should be owned by the team. While the Product Owner may be invited in some cases, having them prioritize process improvements confuses roles and does not solve the timebox or outcome problems.

• ✓

  Structure the retrospective with clear phases, timebox each phase, and reserve the final portion for selecting one or two improvement actions.

  Why this is correct

  A structured retrospective with timeboxed phases ensures that data gathering, insight generation, and decision-making all get attention. Reserving the final portion for selecting one or two improvement actions guarantees the team leaves with commitments. This approach addresses both the overrun and the lack of outcomes without reducing the event's value. It also models good facilitation and can be adjusted based on team feedback, making it a sustainable improvement to the event itself.

• ✗

  Reduce the retrospective to 30 minutes to force the team to focus on only the most critical issues.

  Why it's wrong here

  Shortening the timebox without changing the format may cause the team to rush through data gathering and skip important steps, leading to superficial outcomes. The problem is not the length but how time is used. A shorter meeting could also reduce psychological safety by making participants feel pressured. The Scrum Master should first improve the structure and facilitation before considering a timebox change, and any change should be agreed upon by the team as an experiment.

• ✗

  Move the retrospective to the end of the iteration and combine it with the Iteration Review to save time.

  Why it's wrong here

  Combining the Iteration Review and Retrospective dilutes both events and removes the dedicated space for team process reflection. The Iteration Review focuses on the product increment and stakeholder feedback, while the Retrospective focuses on how the team works. Merging them would likely shorten or eliminate the retrospective's inspect-and-adapt cycle. This option also ignores the root cause, which is facilitation and structure, not the amount of time available in the iteration.