Halfway through a two-week Sprint, the firmware team at Nestbot discovers one selected Product Backlog item is riskier than expected. They want to swap it for a smaller item that still supports what they committed to delivering. What allows this kind of mid-Sprint flexibility without breaking the Sprint Backlog's commitment?
Select an answer to reveal the explanation.
Short Explanation
The Sprint Goal is what holds a Sprint together even when the specific work underneath it shifts. It gives the Developers a single objective to aim at, so if one path turns out riskier than expected, they can swap in different work that still serves the same goal. As long as the goal stays intact, the plan underneath it is allowed to flex.
Full Explanation
The Sprint Goal exists precisely so a Sprint can absorb new information without collapsing into either rigid lock-step or directionless scope creep. Because the Sprint Backlog items and the plan belong to the Developers, they can renegotiate the specific scope with the Product Owner mid-Sprint as long as the Sprint Goal itself stays intact; swapping the risky firmware item for a smaller one that still supports the goal is exactly that mechanism at work. A formal change-request form invents bureaucracy the Guide doesn't describe and misplaces control with a document rather than a conversation. The Definition of Done governs when a piece of work counts as complete, not whether items can be swapped, so it doesn't grant any substitution authority. Treating the Sprint Backlog as locked until Sprint Review misunderstands emergence: the plan is expected to evolve throughout the Sprint as the Developers learn more, not just at its boundaries. A practical check for Nestbot: when scope shifts mid-Sprint, ask whether the Sprint Goal still makes sense unchanged. If it does, the swap is healthy adaptation; if the goal itself has to change, that's a much bigger conversation.