During Sprint Planning, the Development Team was not able to confidently forecast a Sprint Backlog but the Scrum Team was able to create a Sprint Goal for upcoming Sprint. What action should the…

Question

Options

• APostpone the Sprint in order for the Product Owner to refine the Product Backlog to the level
• BExtend the Sprint Planning time-box until the Development Team can forecast enough items to
• CForecast the most likely Product Backlog items to meet the goal and discuss in the upcoming
• DRequest assistance from the technical architect.

• A
  2% (1)
• B
  7% (3)
• C
  78% (36)
• D
  13% (6)

Explanation

Option C is correct because the Scrum Guide permits the Sprint to begin even when the Development Team cannot fully forecast the entire Sprint Backlog - as long as a Sprint Goal exists. The team selects the most likely Product Backlog items to achieve that goal and uses empiricism (Daily Scrums, inspection, adaptation) to adjust as the Sprint progresses.

Why the distractors fail:

• A is wrong because Scrum does not endorse delaying or postponing Sprints - they flow continuously one after another, and backlog refinement is an ongoing activity, not a prerequisite gate.
• B is wrong because the Scrum Master's duty is to protect the Sprint Planning time-box (max 8 hours for a one-month Sprint), not extend it - violating the time-box undermines the empirical process.
• D is wrong because Development Teams are self-organizing and cross-functional; escalating to an external technical architect undermines team autonomy, a core Scrum value.

Memory tip: Think "Goal unlocks the Sprint." Once the Sprint Goal is set, the team has enough direction to start - they commit to the goal, not a perfect forecast. Scrum trusts the Daily Scrum to surface and resolve uncertainty along the way.

No community discussion yet for this question.