>  Blog

Handling Support Issues in a Sprint

Unpredictable but important support issues crop up in the middle of a sprint. How do we account for these in sprint planning?


Pradyumn Sharma

August 29, 2017


Consider this scenario: your agile team is in the middle of a sprint and an issue crops up in one of the stories delivered in an earlier sprint that needs to be fixed urgently. Some team members need to divert their attention from their current work in order to resolve the issue.

This reduces the momentum of the team (and may impact the velocity and the scope of the sprint).. If such issues keep coming up from time to time, the team may regularly fail to honour its commitments. At the same time we cannot neglect any serious bugs, performance issues, critical support needs, etc.

So how do we account for such unpredictable situations? Can we address these while planning for a sprint?

There are two different approaches that you may consider.



Approach 1: Marking a part of the capacity for support issues

You keep aside some percentage of time, based on recent history, for support work. For example, you may find that in the recent sprints, the team members ended up spending about 20% of their time in support work.

During the Sprint Planning Meeting, you also make an estimate of the capacity of the team, i.e., the number of available hours that all the team members collectively have. Suppose this value turns out to be 300.

Keep aside 20% of the capacity (60 hours) for the support work, and sign up for stories up to 240 hours. If you anticipate more issues during the forthcoming sprint, maybe you keep an additional 5% of the capacity (for a total of 75 hours) for the support work.

If fewer (or simpler) support issues come up, then you have the opportunity to pick up additional, lower priority stories beyond what had been committed for the sprint. Such stories are called slack in Extreme Programming, and are also identified during the planning meeting.



Approach 2: Dedicated support person, by rotation

This is the approach that I prefer more often. If there is a feeling that the product is not very stable, and there may be a significant number of support issues, I advocate keeping one person, by rotation, out of the reckoning, for a sprint. This person then is dedicated for providing such support.

Often, the support work actually does not require full time effort from this "out of scope" person. That provides an opportunity to involve them in other tasks such as coordinating with the Product Owner for detaining the stories for the next sprint (and thereby learning to play the role of a Business Analyst when required), documentation, etc. And in their spare time, this person can implement some slack stories.

This way the rest of the team has more predictability for their productive hours and the quantum of work they can complete. In other words, fluctuations in the quantum of support issues do not have any significant impact on the productivity of the team.

Since you rotate the support responsibility among all the team members, nobody complains about having been saddled with only "dirty" work.

In effect, the idea is that you should have a strategy in place to handle unpredictable situations during the sprints. This means carving out some leg room in the sprint and not stuffing as many stories as you can into one sprint or chasing a higher velocity. This has the benefit of bringing down the risk factors, and improving the predictability of outcomes of your projects over time.