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.

• ✓

  Help the team prepare a working, demonstrable increment and a clear narrative that connects the iteration's work to the Iteration Goals.

  Why this is correct

  The Iteration Review is a show-and-tell of the working increment, so the team must have something demonstrable and a story that ties the work to the Iteration Goals. The Scrum Master supports this by coaching the team on preparation, ensuring the increment meets the Definition of Done, and helping structure the narrative. This keeps the event focused on inspecting the actual product rather than on slideware or status reporting.

• ✓

  Facilitate the event so stakeholders can inspect the increment, ask questions, and provide feedback that informs the team's next iteration.

  Why this is correct

  The Scrum Master facilitates the Iteration Review to ensure stakeholders can inspect the increment and give feedback. This includes managing the flow, encouraging participation, and keeping the focus on the product. Facilitation helps the team and stakeholders engage productively, which enables the team to adapt its backlog based on what is learned during the review, fulfilling the event's inspect-and-adapt purpose.

• ✗

  Convert the Iteration Review into a formal sign-off gate where stakeholders approve the release before the team proceeds.

  Why it's wrong here

  Turning the review into a release sign-off gate changes its purpose from inspection and feedback to governance approval. In SAFe, the Iteration Review is a team event for demonstrating the increment and gathering feedback, while release governance happens through other mechanisms such as the System Demo and release management. The Scrum Master should protect the event's purpose rather than morph it into an approval checkpoint that slows learning.

• ✗

  Approve the final acceptance of each user story with stakeholders before the team demonstrates the increment.

  Why it's wrong here

  Acceptance decisions belong to the Product Owner and stakeholders, not the Scrum Master. The Scrum Master facilitates the event but does not gate the demonstration by pre-approving stories. Inserting an approval step before the demo adds ceremony and delays feedback, undermining the review's purpose of rapid inspection and adaptation. The team demonstrates the increment, and stakeholders provide feedback that the Product Owner uses to adjust the backlog.

• ✗

  Present the team's velocity charts and burn-down metrics on behalf of the team to demonstrate progress to stakeholders.

  Why it's wrong here

  Metrics can inform the review, but the Scrum Master presenting them on the team's behalf displaces the team's ownership of its work and turns the event into a status briefing. The Iteration Review centers on the working increment and stakeholder feedback, not on a metrics presentation delivered by the Scrum Master. The team should speak to its own progress and learning, with the Scrum Master facilitating rather than presenting.