Rules of Engagement for Changing Agreed Sprint Commitments | David Tzemach

A common misconception of Scrum enthusiasts is that the sprint backlog remains static during the sprint. This means no changes are allowed during the sprint and work items cannot be added or removed.

This is simply not true. While in theory it may sound good, in reality this approach does not work. This is because in software development projects, changes happen frequently and the environment changes constantly. All this results in the sprint backlog changing. We must strive to minimize the impact on the team and their ability to achieve the sprint goal.


The sprint goal is a fundamental aspect in Scrum; it directs the team to focus on what must be achieved by the end of the sprint. Therefore, the sprint goal is fixed during the sprint, while the sprint backlog is not. Thus, one can say that the sprint backlog is used only to represent items that help the team achieve its goal. If there are new insights, impediments or an urgent customer requests that emerge, the team must have the ability to succeed and overcome them.


As issues emerge, a conversation between both the PO and the development team must occur. During the discussion, each side will share its insights on whether to modify the backlog and what impact it will have on other commitments and especially on the sprint goal.



For this reason, the Scrum guide has been updated in the last few years to support the concept of a dynamic sprint backlog. This means the team is "forecasting" instead of "committing" to the work they will deliver. By doing so, the team will have more space to embrace the changes that may arise during the development cycle as they are not "committed" to a specific story.


It is essential to understand that changes to the sprint backlog will occur. Therefore, to limit the impact of these changes on the sprint and consequently on team morale, it is important to set a clear process to manage these changes.


The following are some of the rules I have used with my teams:

  1. Both the PO and development team can suggest sprint backlog changes throughout the sprint.

  2. If the change has a direct impact on the team’s ability to achieve the Sprint goal, approval must be received from the PO.

  3. The team can add any technical story arising during the sprint as long as it does not impact the delivery of other stories. In any case, it must be added and approved by the PO in case there are changes in priority.

  4. The team can remove any of their technical tasks if they are not necessary. However, the PO must be informed of this so that new stories can be added to the existing Sprint.

  5. The team is not allowed to remove functional stories from the sprint backlog (Only the PO can remove things from the Sprint Backlog, if it no longer provides business value).

  6. If there is a story that cannot be met, then there is a possibility of replacing it with another item from the backlog. This can be done only if the following conditions are met:

  7. The story has similar estimations and expected team effort.

  8. It has received the approval of the PO and development team.

  9. A retrospective is done at end of the sprint to understand why the item was not achievable.