SSM Introducing Scrum in SAFe Practice Question
During an Iteration Review for a team adopting SAFe Scrum, a stakeholder expresses frustration that a major user story was not completed because the team spent unexpected time fixing architectural defects. The Product Owner accepted the partial work. How should the Scrum Master address this?
⚠ Common exam trap
Many practitioners believe that if a story is mostly finished or blocked by technical debt, the Product Owner can accept partial credit to show progress.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Coach the team and Product Owner on the Definition of Done, ensuring only fully completed stories are accepted and counted.
The Scrum Master must coach both the Product Owner and the team on the strict definition of done, emphasizing that incomplete stories cannot be accepted as done simply because some work was performed. Unfinished stories must return to the backlog for re-prioritization in future planning cycles.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Instruct the Product Owner to mark the story as complete in the tracking tool so the velocity metrics remain artificially high.
Why it's wrong here
Falsifying completion corrupts the tracking tool's data, destroying the transparency the Iteration Review exists to provide, and hides the architectural defect trend. It is tempting because velocity metrics look healthier, and accurate reporting would be right where the story genuinely met its acceptance criteria.
- ✓
Coach the team and Product Owner on the Definition of Done, ensuring only fully completed stories are accepted and counted.
Why this is correct
Enforcing the Definition of Done ensures quality standards remain high and prevents technical debt from accumulating unnoticed. When stories fail to meet criteria, they must not be accepted, preserving accurate metrics and transparent progress tracking.
- ✗
Advise the team to skip writing automated unit tests in future iterations so they can deliver features faster under pressure.
Why it's wrong here
Skipping automated unit tests removes the Built-In Quality practice that would surface architectural defects earlier, increasing the rework consuming iteration capacity. It is tempting because dropping tests appears to free capacity, and reducing test scope would suit a deliberate, risk-assessed trade-off on a low-criticality increment.
- ✗
Blame the System Architect for failing to provide clear technical guidelines before the iteration started.
Why it's wrong here
Blaming the System Architect assigns individual fault for a systemic architectural defect pattern, which suppresses the honest disclosure the review depends on. It is tempting because accountability feels decisive, and direct feedback to an architect would suit a specific, evidenced design decision that caused a known failure.
About these practice questions
This SSM question is part of Courseiva's 385-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Scaled Agile exam blueprint
This SSM practice question is part of Courseiva's free Scaled Agile certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SSM exam.