Rules of Engagement for Changing Agreed Sprint Commitments | David Tzemach
Updated: Mar 3, 2022
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 not true. While it may sound good in theory, this approach does not work in reality. This is because changes frequently happen in software development projects, 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 new insights, impediments, or urgent customer requests emerge, the team must have the ability to succeed and overcome them.
As issues emerge, a conversation between the PO and the development team must occur. During the discussion, each side will share its insights on modifying the backlog and its impact on other commitments, 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. The team will have more space to embrace the changes 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 essential to set a transparent process to manage these changes.
The following are some of the rules I have used with my teams:
The PO and development team can suggest sprint backlog changes throughout the sprint.
If the change directly impacts the team’s ability to achieve the Sprint goal, approval must be received from the PO.
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.
The team can remove any of their technical tasks if necessary. However, the PO must be informed to add new stories to the existing Sprint.
The team cannot remove functional stories from the sprint backlog (Only the PO can remove things from the Sprint Backlog if it no longer provides business value).
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:
The story has similar estimations and expected team effort.
It has received the approval of the PO and development team.
At the end of the sprint, a retrospective is done to understand why the item was not achievable.