Get certified - Transform your world of work today

Close

Deal with It, but Don’t Forget to Feed the Continuous Improvement Engine!

Dealing with change during a sprint

4 September 2014

Manoj Vadakkan
Northern Star Consulting


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?
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.5 (2 ratings)

Comments

Tim Baffa, CSM, 9/4/2014 4:10:04 PM
Good article. I like the reflective questions you listed as well - good team retrospective approach.

I personally do not support modifying any accepted stories within a sprint. If the PO wants to add or update a story because of missed or changing requirements, I would ask the PO if the change is worth restarting the sprint (i.e. - canceling the current sprint). In almost all instances, it is something that was missed but could wait for the next sprint.

Granted, this should be tempered with the ultimate goal of providing the business with workable software.

My concern is around the idea that Scrum and the sprint iteration are providing a level of certainty around a highly variable effort (software development). Introducing change, even minor, defeats this purpose. Including change also involves PO and team refinement activities, and team estimating/re-estimating. These efforts are unaccounted for at sprint start, and therefore should not be mid-sprint activities.
Manoj Vadakkan, CST,CSP,CSM,CSPO,REP, 9/4/2014 4:38:50 PM
Tim, Thank you for your comment. I agree. When disruptions become the norm, we lose our ability to forecast. Definitely something to discuss at the retrospective meeting and take actions to reduce the chances of it happening again.

You must Login or Signup to comment.

 
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


 

Newsletter Sign-Up

Subscribe