At the end of a Sprint, the Developers complete only three of the five Product Backlog items they forecast during Sprint Planning, though the Sprint Goal was achieved. A stakeholder accuses the team of breaking its commitment. How should the Scrum Master respond?
Select an answer to reveal the explanation.
Short Explanation
Not every number on the plan is a promise, the Sprint Goal is. If the team hit the goal but not every single item on the list, that's forecasting doing its job, not a broken deal.
Full Explanation
The mechanism is the Guide's explicit split between the Sprint Goal, described as a commitment, and the selected Product Backlog items, described as a forecast of what the Developers expect to complete, so meeting the goal while missing some forecast items is not a failure, it's forecasting working as intended under real conditions. Agreeing a commitment was broken accepts a false premise and risks pushing the team toward sandbagging future Sprints out of fear of criticism, which corrodes honest forecasting. Having the Scrum Master personally take on completing the items misassigns work away from the self-managing Developers and treats the situation as a debt to repay rather than a normal forecasting outcome. Recommending unpaid weekend work to hit an arbitrary number treats the original forecast as more sacred than the Sprint Goal it was meant to serve, inverting their actual relationship. Caveat: repeatedly missing forecast items by a wide margin is still worth inspecting at the Retrospective, even when the Sprint Goal is met. Operational check: at the Retrospective, look at why the forecast diverged from the goal-relevant items actually completed, and adjust future forecasting habits accordingly.