Handling Intra Sprint Changes

During my coaching sessions at various organizations, I am frequently faced with the question - "How do we take care of the blocker issues that arise while we are in the middle of a Sprint?" This seemingly is a very genuine concern coming from everyday experience of traditional way of working, wherein, there are enough number of people with enough authority to "command" teams to take up some unplanned "blocker" issues irrespective of what the team is currently doing.

In this blog post, I would attempt to answer this question.

I have a dual intention here:

1. Share my views and experience on the topic

2. Solicit the experience, advise and views of our community on the same

First we need to differentiate between "high priority work" and genuine "blockers". Many a times, we fail to draw a line thereby trying to accommodate anything and everything that comes our way, putting our teams under undue pressure. Scrum (and its value) is the first thing to go out of window under such a setup. Here, the role of the ScrumMaster becomes paramount. The SM needs to ensure that before any "external interference" or unplanned work reaches the team, he/she acts as a shield and ensure that the incoming work is a genuine blocker that will cause business / revenue loss if not addressed immediately.

Once that is done, I have seen three approaches, depending on the volume and pattern of the incoming unplanned "blockers", to handle such work while the team is into their commitment (sprint).

Ping-pong Scrum

Ping-pong Scrum, as I call it, is applicable in the case where the team is spending almost as much energy / time / effort on unplanned work as on the planned (committed) work.

In such cases, it might make sense to split our Scrum team into 2 sub-teams: Team A and Team B. This iteration, Team A works on planned work (as per SBL), while team B takes care of unplanned work. No one would like to be in team B for a long time. Hence next iteration, we switch: Team A on unplanned work, while Team B takes care of planned work.

Buffered Scrum

Buffered Scrum finds use in the case where the volume of unplanned activities put upon the team is high but not really as high as the planned work itself. Herein, the team keeps a buffer for such anticipated-but-yet-unknown work and commit less than their real capacity. Its important to make sure, this is clearly explained to the PO. A basic fundamental on which Scrum works is transparency and trust. The Product Owner should be aware that the team is committing for less than what they can actually do, because even if the team commits at their 100% potential, chances are, they will fail due to unavoidable unplanned work. Even if the team has a buffer, it should be very prudent as to when to say "yes" to unplanned work. Uncle Murphy's law - if we say "yes" to all incoming requests, then, just when our buffer is full, we will get a genuine blocker. Hence the team and the SM, better watch out for the severity of the incoming work.

In a case wherein, not enough unplanned work pours in to fill up the buffer, in a specific sprint, the team always has an option to go to the Product Owner and ask for more work.

In cases where the unplanned work comes in, but there is no pattern or frequency of the same, we can neither go for ping-pong scrum nor for buffered scrum. In such cases, it might be best to proceed with our regular Scrum. If and when a blocker work comes in, the SM, after ensuring its "blocker-ness", asks the team to size the unplanned work. Next, the SM asks the team if they can accommodate the incoming change without stretching (due to built in buffer - that is, when the team commits to less than their 100% capacity during planning meeting because no other piece of work was small enough to fit-in).

If the team can accommodate the same, we are good, else, the SM discusses with the PO if some of the committed backlog work be traded off so that this blocker issue can be traded in (provided the team has not already started on that committed user story). If that can be done, we are good again.

If nothing else can be done and the person who escalated the blocker agrees that it is urgent enough to stall the sprint, the current sprint is stalled and the team immediately goes into the next planning meeting with this blocker issue going to the commitment (SBL) by default. This however should be an exception and not a norm.

Its important to understand that none of the above approaches is "recommended" by Scrum per se. All these are "inspected and adapted" ways that are working well at various work places. They may or may not work for other work places. We'll have to try out to know more!

Looking forward to understanding your views community...