A home-robot company's app Developers finish their planned work three days before the Sprint ends. Rather than waiting idly, they decide among themselves to pull in and start a smaller, related Product Backlog item that supports the same Sprint Goal. Is this consistent with the Scrum Guide?
Select an answer to reveal the explanation.
Short Explanation
The Sprint Backlog isn't sealed the moment Sprint Planning ends — it's a living plan the Developers keep adjusting as they go. Finishing early and pulling in more supporting work is exactly the kind of self-managed adaptation the Guide expects, as long as it still serves the same Sprint Goal.
Full Explanation
The 2020 Scrum Guide describes the Sprint Backlog as a highly visible, real-time picture of the work the Developers plan to accomplish, which they update throughout the Sprint as more is learned — it is not frozen the moment Sprint Planning ends. The Developers pulling in a related item that still serves the existing Sprint Goal is a normal expression of self-management, since they decide how to organize and adapt their own work during the Sprint. Saying only the Product Owner can add Sprint Backlog items conflates Product Backlog ordering, which is the Product Owner's accountability, with managing the Sprint Backlog's contents during execution, which belongs to the Developers. Claiming the Sprint Backlog is fixed for the whole Sprint misreads the Guide's actual position — the Sprint Goal is meant to stay stable, and that stability is precisely what allows flexibility in how the backlog is executed underneath it. Requiring Scrum Master approval before pulling in more work also adds a permission step the Guide does not include; the Scrum Master doesn't gatekeep the Developers' internal Sprint Backlog adaptations. The operational boundary to watch is the Sprint Goal itself — new work is fine as long as it doesn't quietly renegotiate what the Sprint was meant to achieve.