Dealing with Change During a SprintDeal with it; but don’t forget to feed the continuous improvement engine!
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?