Here’s How To Deal With Change In The Middle Of The Sprint

By / January 22, 2016 /

In agile development community, we get a lot of “what if” questions. “What if the product owner decides to change a story in the middle of the sprint? What if he adds a new story altogether?” or “What if a crucial team member slips on banana peel and becomes immobile for a significant period of time?”

Deal with it

The short answer to those mind-boggling questions is “Deal with it.” Then we might add “Just make sure that the issue is addressed during the next retrospective meeting so it won’t happen again.”

Let’s take take a closer look at the “changing the story” question first. During the sprint planning meeting, the team members agreed on how much work was to be completed during the sprint. Imagine that somewhere along the way, the product owner wants to add a new story or substantially change the existing story. Now, we could safely assume that the product increment for the current sprint is in danger of not being completed. However, if the change is minor, then we shouldn’t worry and just carry on with our work, knowing that it won’t cause much disruption (especially if it’s aligned with our overall goal).

The Scrum Master is the first person who deals with these kinds of things. He needs to keep the extraneous details from distracting the team and ensure that everything is running smoothly. As a righteous protector of the realm, the Scrum Master may ask:

  • Is that change that you’re trying to implement during the sprint really so important?
  • Can we push this change to the next sprint?
  • Let’s have a look at the task board and see if we can fit in any additional work into the sprint.
  • If after all these questions, the product owner still wants to go along with the change, then the onus falls on the team.

There are few questions that the team must answer (in no particular order):

  • Is this new story in line with the overall goal of the sprint?
  • Is it possible that we’ll lose our focus by adding this story?
  • Can we asses the impact that this story will have on our original plan?
  • Does adding this story makes us work at unreasonable pace? What was the velocity of our last few sprints?
  • Is this story very significant to the product owner?

Sitting side by side with the product owner, the team will look into the matter more deeply and then come up with a viable solution. The possible outcomes are:

  • We’re on it (if the amount of work is small enough.)
  • We’re on it, but we need to make some additional adjustments (such as eliminating something of lower priority from the list).
  • Nope. We have to add this thing to the next sprint and put it the product backlog refinement activity.
  • Maybe (adding the Indian Headshake wouldn’t hurt here). We need to look into the matter and we’ll decide later.

Initiating the constant improvement engine:

No matter how the team decides to deal with the situation, the item needs to be addressed in the retrospective. During this process, you can ask the following questions:

  • Did we lose precious time because of the proposed change?
  • How can we deal with this kind of situation in the future?
  • Was our sprint too long? Maybe next time we should use shorter sprints to deal with the change faster?

During this retrospective meeting, the team has to come up with some solutions that will prevent disruptions from happening again. That’s how you get better over time – that’s constant improvement!

This post has been viewed 1,416 times