SSM Introducing Scrum in SAFe 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.

• ✗

  Convert the Iteration Review into a second Retrospective so the team can focus solely on its internal process.

  Why it's wrong here

  The Retrospective already exists to inspect and improve the team's process. Converting the Iteration Review into another Retrospective eliminates stakeholder inspection of the product increment and removes the feedback loop that validates value delivery. The two events serve distinct purposes in Scrum and SAFe, and merging them leaves the team without external validation of what it built.

• ✗

  Replace the Iteration Review with a written status report distributed to stakeholders at the end of each iteration.

  Why it's wrong here

  A written status report removes the inspection and adaptation that the Iteration Review provides. SAFe expects the team to demo working, tested software to stakeholders so feedback can shape the backlog. Replacing the event with reporting also disconnects the team from the train's System Demo and reduces transparency, which is the opposite of what the Scrum Master should coach.

• ✓

  Invite stakeholders, coach the team to demonstrate the working increment, and use the feedback to adapt the backlog.

  Why this is correct

  The Iteration Review is an inspect-and-adapt event where the team demonstrates the increment to stakeholders and captures feedback. By inviting stakeholders and coaching a demo of working software, the Scrum Master restores the event's purpose. The feedback then informs the Product Owner's backlog ordering and can feed the train-level System Demo, improving alignment across the Agile Release Train.

• ✗

  Ask the Release Train Engineer to present the team's results at the next System Demo instead of holding a team-level review.

  Why it's wrong here

  The System Demo is a train-level event that integrates the work of all teams, but it does not replace the team's own Iteration Review. Skipping the team-level event removes the frequent, team-focused feedback that helps the team adapt within the iteration cadence. The Scrum Master should strengthen the Iteration Review, not outsource its purpose to a larger event.