Partway through a Sprint, the Developers on the firmware team realize two of the Product Backlog items they selected during Sprint Planning will take longer than expected, but the core capability behind the Sprint Goal is still achievable. What should the Developers do?
Select an answer to reveal the explanation.
Short Explanation
The list of items picked at Sprint Planning was always a best guess, not a contract, it's the Sprint Goal that the team is actually on the hook for. When new information shows up mid-Sprint, the smart move is to adjust the plan, not blow up the goal it was serving.
Full Explanation
The mechanism is the distinction the Scrum Guide draws between the Sprint Goal, which is a commitment, and the selected Product Backlog items, which represent a forecast of what the Developers expect to accomplish. As new information emerges during the Sprint, the Developers are expected to collaborate with the Product Owner to renegotiate scope without compromising the Sprint Goal, since it's the goal, not the exact item list, that anchors the Sprint's focus and coherence. Abandoning the Sprint Goal and restarting Planning discards a still-achievable commitment over a forecasting miss, which is a bigger disruption than the situation calls for. Having the Scrum Master assign work to individuals contradicts self-management: the Developers, not the Scrum Master, decide who does what. Extending the Sprint breaks the Sprint's fixed timebox, which the Guide does not allow, since Sprints are never lengthened to fit unfinished work. Caveat: renegotiating scope is not a license to quietly drop anything inconvenient; it should be transparent to the Product Owner and visible on the Sprint Backlog. Operational check: at the next Daily Scrum, make the scope adjustment explicit so it's inspectable by the whole Scrum Team.