PSPO 1/PSM 1 Type of Question - Sprint Backlog Item Changes during the Sprint - Trying to Resolve Inconsistencies

The Sprint Backlog is a plan or forecast of the work which will be needed to meet the agreed Sprint Goal. The team should adjust that forecast during the Sprint as more is learned about the evolving product increment. The Daily Scrum is an opportunity for such replanning to occur. The fixing of Sprint Backlog scope ought to be avoided as it may compromise the team's ability to meet the Sprint Goal. 

Ian,

Thank you for your response.

I do understand that the Sprint Backlog includes a plan for the work which will be needed to be done to meet the Sprint Goal.  The team should adjust that plan during the Sprint as more is learned about the scope of the work of the Sprint.  So the plan emerges during the Sprint. This part of the plan is what I refer to in my above question as the tasks, or work, or scope, which is decomposed from the Product Backlog Items (PBIs) selected by the team for the Sprint.

However, the part of the Sprint Backlog that I am asking about in terms of changes are the actual Product Backlog Items selected by the team for the Sprint during Sprint Planning, which I refer to as Sprint Backlog Items.  The point about keeping the Sprint Backlog Items fixed is not mentioned in the Scrum Guide but discussed in multiple other sources.  One source includes Jeff Sutherland’s current web site, Sruminc.com, which states:  “Once the team forecasts the number of stories they feel they can accomplish in the Sprint Backlog, there should be no additions or changes until the Sprint ends” (otherwise there will be what is considered to be an interruption to the Sprint and an exception process would have to be followed). 

There are definitely benefits to keeping the Sprint Backlog Items as fixed as possible, including providing a safe environment for the developers to remain focused and as productive as possible during the short duration of a Sprint time-box to ensure quality goals are met.  There may be the need to re-negotiate scope for a Sprint Backlog Item (User Story) and deliver an item with a smaller scope than originally planned and then add a new user story to the Product Backlog for the rest of the scope for a later Sprint.  However, that’s a change in the meaning/scope of an item, rather than the item itself.

Based on your response, are you saying that the concept of a somewhat fixed set of Sprint Backlog Items selected from the Product Backlog for the Sprint is no longer applicable and you can add, change, remove or replace Sprint Backlog Items during a Sprint to better meet the Sprint Goal, perhaps as long as both the Development Team and Product Owner agree?  Are there any specific rules/limitations regarding the types of changes that could be made to Sprint Backlog Items during the Sprint?

Please let me know.

Thank you for your help,

Karen Sullivan

The Scrum Guide is the definitive expression of the Scrum Framework. Hence the Sprint Backlog in its entirety, including selected Product Backlog Items, is mutable. Only the agreed Sprint Goal is fixed.

Changes to the Sprint Backlog, including including the selection of PBI's, should help the team to meet the Sprint Goal. Any additions changes, or removals should not put the Goal at risk. If there is an adjustment to the forecast of PBI's then that scope change should not compromise the Goal.

The Product Owner has final authority over whether a change to the selection of PBI's in a Sprint Backlog would help or hinder the achievement of the agreed Sprint Goal. However, the Sprint Backlog wholly belongs to the Development Team and only they are autborized to make any such changes. 

Ian,

Thank you very much for your answer to this question as well as to my other questions from the group of questions that I originally posed and that you suggested that I break up into separate posts.  I do appreciate your responses.

To be very honest with you, the reason why I asked this particular question multiple ways was because I feel that not having a somewhat stable set of PBIs during the short duration of a Sprint time-box takes away from a key benefit of Scrum, which is - providing a safe environment for the developers to remain focused and as productive as possible during the short duration of a Sprint time-box to ensure quality goals are met.  Using a fixed Scope approach is very good from a Scope Management perspective because you are not constantly changing the items in the Sprint Backlog and are allowing the team to focus on getting work done and to deliver quality results during the Sprint.  You are still being Agile by adapting changes at the end of every Sprint based on Stakeholder feedback at the Sprint Review as well as with other discussions the Product Owner has with stakeholders that enable changes to be made to the Product Backlog.

Your response to my question brings me to ask why not just use a continuous (more flexible) approach such as Kanban or ScrumBan where there are no Sprints or Sprint Backlogs but you have full flexibility in terms of changing the items to meet the Sprint Goal at any time? 

Please let me know.

Thank you again for your help,

Karen Sullivan

A Kanban team would not typically be expected to commit to and focus on an overarching goal, on cadence. The ability to do so can be helpful when mitigating the significant risks which underlie complex systems development. That's the essence of a Sprint Goal. 

In Scrum, the Sprint Backlog (i. e. the plan and forecast of work) can be changed at any time if it helps the Development Team to meet the Goal. Any change which would result in instability and put the Goal at risk should be avoided. The team should always know how much work is believed to remain and should be able to evidence good Sprint control. 

Note that Scrum, as a framework, is non-prescriptive about how a team makes its commitments. If it would be advantageous for a team to commit to certain specific items in a Sprint Backlog then they are free to do so. The important thing is that all Scrum Team members, including the Development Team and the PO, have a clear and shared understanding of this. 

Ian,  Thank you for your feedback.  It is very helpful.  Karen Sullivan