Dealing with Change During a Sprint
Deal with it; but don’t forget to feed the continuous improvement engine!
by Manoj Vadakkan, CST
As the day goes by on a typical CSM class, I get a lot of “what if?” questions from students. For example “what if the Product Owner adds a new story or changes a story during the sprint?” or “what if a critical team member got sick for several days during the sprint”
A quick answer to these questions usually goes like this: Deal with it. Then I add, make sure this is brought up in the retrospective meeting so we minimize the chances of problems like this interrupting next sprints. Interestingly, towards the end of the class, when some one starts a question with “what if….” Someone else will chime in, “Deal with it….”.
Let’s look at the first question a little deeper. In this case, you are in a team that is practicing Scrum. At the Sprint Planning meeting, the team had created forecast of how much work they can complete during this sprint. Sometime in the middle of the sprint, the Product Owner is trying to add a new story or significantly change a story. Let’s assume that the forecast and the product increment for the current sprint is potentially in jeopardy because of this change. If that is not the case, for example it is a minor change or a small enough story, I would go ahead with the change especially if the change or the new story aligns with the goal of the sprint.
Usually, the first role to deal with this type of change will be the ScrumMaster. The ScrumMaster needs to protect the team from external interferences. As a ScrumMaster, that would be the first thing I would try to do. I would wear that “Protector outfit” and stand between the Product Owner and the team and ask questions such as:
Yes, responding to change is weighed more than following a plan. However, Focus also is one of the values of Scrum. Also important is that the team works at a sustainable pace.
If the Product Owner still wants to entertain this change after considering the questions above, then it is the team that needs to deal with it.
Some of the questions I would ask the team (in no particular order) are:
Working with the Product Owner, the team now will investigate this further and come up with how they will deal with it. The outcome of this might be a:
Very rare but a possible option is to terminate the current sprint and start a sprint planning session. Product Owner is the final authority on making that decision.
Feeding the Continuous Improvement Engine
In whatever way the team decides to deal with it, it is important that this event is brought up in the retrospective: Some of the questions that are to be considered in the Sprint Retrospective are:
At the retrospective, the team needs to identify some actions to minimize disruptions during the next sprints. That is how the team improves their way of working. That is continuous improvement!
How are you dealing with change? Tell us your experience. What questions or options would you include in these discussions above?
A quick answer to these questions usually goes like this: Deal with it. Then I add, make sure this is brought up in the retrospective meeting so we minimize the chances of problems like this interrupting next sprints. Interestingly, towards the end of the class, when some one starts a question with “what if….” Someone else will chime in, “Deal with it….”.
Let’s look at the first question a little deeper. In this case, you are in a team that is practicing Scrum. At the Sprint Planning meeting, the team had created forecast of how much work they can complete during this sprint. Sometime in the middle of the sprint, the Product Owner is trying to add a new story or significantly change a story. Let’s assume that the forecast and the product increment for the current sprint is potentially in jeopardy because of this change. If that is not the case, for example it is a minor change or a small enough story, I would go ahead with the change especially if the change or the new story aligns with the goal of the sprint.
Usually, the first role to deal with this type of change will be the ScrumMaster. The ScrumMaster needs to protect the team from external interferences. As a ScrumMaster, that would be the first thing I would try to do. I would wear that “Protector outfit” and stand between the Product Owner and the team and ask questions such as:
- Is it really that important to make this significant change during the sprint?
- What if we waited until the next Sprint to include this change?
- Let’s look at the task board together and learn more about our progress now and see the likely impact of this change.
Yes, responding to change is weighed more than following a plan. However, Focus also is one of the values of Scrum. Also important is that the team works at a sustainable pace.
If the Product Owner still wants to entertain this change after considering the questions above, then it is the team that needs to deal with it.
Some of the questions I would ask the team (in no particular order) are:
- Would the team lose focus by entertaining the inclusion this story?
- Does the story align with the Goal of the Sprint?
- Do we know enough about the change /new story to assess the size and impact to original goal/forecast?
- By picking up this additional story, does the team have to work in a non-sustainable pace? How was the pace of the last few sprints?
- For the Product Owner, how important is this story to be included in this sprint? If it is important, is the Product Owner open to reorder existing stories?
Working with the Product Owner, the team now will investigate this further and come up with how they will deal with it. The outcome of this might be a:
- Yes, we will do it. (The Team decided to just pick it up in the current sprint because work is small enough and change is important enough.)
- Yes, and we make this additional change (such as remove a lower priority story out of scope).
- No, let’s add this as a possibility for the next sprint and include this in the Product Backlog refinement activity now.
- Maybe we should have a team member or two investigate this further and make a decision later. (Remember we will lose further focus when we do this).
Very rare but a possible option is to terminate the current sprint and start a sprint planning session. Product Owner is the final authority on making that decision.
Feeding the Continuous Improvement Engine
In whatever way the team decides to deal with it, it is important that this event is brought up in the retrospective: Some of the questions that are to be considered in the Sprint Retrospective are:
- Did this discussion about the change and actions take away significant time and focus from the team? (If not, we may not have to discuss this further)?
- What event brought up this new information that resulted in this change or additional story? Is that event likely to happen again? How would we minimize this type of disruption?
- Did we miss a Stakeholder in our past Backlog Refinement meeting or miss to engage them otherwise?
- Is our Sprint too long? If we had a shorter Sprint, would the Product Owner likely have avoided interrupting the current sprint and waited for the next Sprint planning for his change?
At the retrospective, the team needs to identify some actions to minimize disruptions during the next sprints. That is how the team improves their way of working. That is continuous improvement!
How are you dealing with change? Tell us your experience. What questions or options would you include in these discussions above?
