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.

• ✓

  The team pulls work from a prioritized Team Backlog and determines how much it can complete within the iteration

  Why this is correct

  In Scrum inside SAFe, the team pulls from a prioritized Team Backlog and forecasts how much it can deliver in the iteration, rather than receiving a fully pre-assigned workload. This pull-based, capacity-aware planning is a defining characteristic that distinguishes the team's way of working from traditional push-based project assignment.

• ✗

  The team assigns each user story to a single specialist who owns it end to end and reports status to the functional manager

  Why it's wrong here

  Assigning stories to individual specialists and reporting to functional managers reinforces silos and external direction. SAFe teams are cross-functional and self-managing, collaborating to complete stories together and reporting progress transparently at team events, so this option describes a functionally siloed approach rather than Scrum within SAFe.

• ✓

  The team delivers a potentially shippable increment of value at the end of each iteration

  Why this is correct

  Each iteration should produce an integrated, potentially shippable increment that is demonstrated at the Iteration Review. This cadence of delivering value frequently, rather than reporting percent complete on a long plan, is a core characteristic that separates Scrum team delivery in SAFe from traditional project management reporting.

• ✗

  The team reports percent complete against a detailed baseline schedule to the Project Management Office each iteration

  Why it's wrong here

  Percent-complete reporting against a baseline schedule is a traditional project management practice. In SAFe, progress is demonstrated through working increments at the Iteration Review and through PI Objectives and Program Board status, not through earned-value style reporting to a PMO, so this option describes the old model rather than the team's new way of working.

• ✗

  The team commits to a fixed scope defined at the start of the Program Increment and cannot adjust it during iterations

  Why it's wrong here

  SAFe treats the PI as a timebox with a fixed capacity and generally fixed PI Objectives, but scope inside iterations is negotiable as learning occurs. A rigid, unchangeable iteration scope contradicts the inspect-and-adapt nature of Scrum and misrepresents how teams manage emerging work during the PI.