There is a common doubt among those considering using Agile methodologies to manage a project: would it be possible to apply Scrum to projects where, on top of the upcoming and planned tasks, there are frequent interruptions to solve maintenance problems, to correct errors or to resolve issues? Many project managers face these types of problems and use several approaches to tackle them. Let’s see some of those approaches: 

Short sprints

With this solution, we will keep the tasks that have already been programmed for that sprint. If our sprints are 1 or 2 weeks long, we will be able to make the unplanned tasks a priority on the to-do list for the next sprint. If the sprint is one week long, we will start urgent tasks after 3 days, on average.
In an ideal world, this would work but it would pose some disadvantages. Not every issue can wait for a few days to be solved. A whole service could depend on it.

 

Low load factor

If we know that as a general rule we will have unplanned tasks or issues that we must solve quickly, we can lower our load factor during the sprint so we have “room” to solve these problems.
If in each sprint the team has the capacity to solve 10 planned stories, we could promise to deliver just 7, so the team has time to solve urgent issues. That way we won’t fail when it’s time to deliver what we promised, sprint after sprint.

In my opinion this solution can be useful in some projects but it could create another problem. Let me explain. Normally the load factor is 75%. If we lower it so we’re able to devote 30% of the team’s time to urgent tasks, we should apply a load factor ranging from 40 to 50%. On this 40% we’re using Scrum but, how are we managing the rest of the team’s time? What do we know about that pile of tasks that we’re solving sprint after sprint?

 

A different team for each type of task

This solution consists of having a Scrum team for the identified and planned tasks, and a Kanban team for the urgent issues. With Kanban we can add new tasks to the TO-DO column as they arrive, and we will follow them up until they get shifted to the DONE column. With this the team will be even more agile, reducing the overhead in meetings and planning that we could suffer with Scrum.
We still have a dilemma with unplanned tasks, which are, well, unplanned. There will be times when the Kanban team providing support will be oversized, because there are very few issues. But then a week later the number of issues and their importance could be so high that we will need any help we can get.

To minimise those risks, we could rely on the previous solutions. We could have short sprints, so the Scrum development team can plan the tasks for the next iteration. We could also use a lower load factor so the team can have a bit of room in their planning to give a hand if needed. In the same way, the support team can help with planned sprint tasks when their TO-DO column starts to look empty. To make the most of this, it would be good if all members in all teams rotated, so that everyone knows every aspect of the job.