Deal with It

This article was originally published on Scrum Alliance website in Sep 2014

As the day goes by in a typical CSM class, I get a lot of “what if?” questions from students. Some of these questions go this way: “What if the product owner adds a new story or changes a story during the sprint?” or “What if a critical team member gets 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 you minimize the chances of similar problems interrupting the next sprints.” Interestingly, toward the end of the class, when someone starts a question with “What if. . . ,” someone else will chime in, “Deal with it.”

Let’s look at the first question a little more deeply. In this case, you are on a team that is practicing Scrum. At the sprint planning meeting, the team created a forecast of how much work they could complete during the sprint. Sometime in the middle of the sprint, the product owner tries to add a new story or significantly change a story. Let’s assume that the forecast and the product increment for the current sprint are potentially in jeopardy because of this change. If that is not the case — for example, if it is a minor change or a small enough story — I would go ahead with the change, especially if it 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 weighted more than following a plan. However, focus is also 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 of this story?
  • Does the story align with the goal of the sprint?
  • Do we know enough about the change/new story to assess its size and impact on the original goal/forecast?
  • By picking up this additional story, does the team have to work at an unsustainable pace? How was the pace of the last few sprints?
  • For the product owner, how important is it to include this story in this sprint? If it is important, is the product owner open to reordering existing stories?

Working with the product owner, the team now will investigate this further and come up with ways to deal with it. The outcome of this might be:

  • Yes, we will do it. (The team decided to just pick it up in the current sprint because the work is small enough and the change is important enough.)
  • Yes, and we will also make this additional change (such as removing a lower-priority story).
  • No, let’s add this as a possibility for the next sprint and include it 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 some focus if we do this.)

A very rare but a possible option is to terminate the current sprint and start a sprint planning session. The 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 it further.)
  • What event brought up the 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 out on engaging them otherwise?
  • Is our sprint too long? If we had a shorter sprint, would the product owner likely have avoided interrupting the current sprint, instead waiting for the next sprint planning meeting to bring up his change?

At the retrospective, the team needs to identify some actions to minimize disruptions during the upcoming sprints. That is how the team improves its way of working. That is continuous improvement!

What is your experience?

How do you deal with changes? Tell us your experience. What questions or options would you include in the discussions above? – See more at:

Leave a Reply

Your email address will not be published. Required fields are marked *