Scrum is a timeboxed framework. We have sprints of fixed length (i.e. two weeks) and during the Sprint Planning event the team decides what will be completed during this time. If additional work comes up it would ideally be put into the product backlog and pulled into a future sprint once prioritized by the product owner, and given the team’s capacity for this work. However, it is not uncommon that we have requests which cannot be delayed until future sprints (i.e. 3rd level/production support). I will describe an approach on how these can be dealt with below.
Interruptions can come in many forms. These may be issues from production, support requests from the Ops team, or bugs that need to be investigated. A new feature request may suddenly become super important and need analysis or a stakeholder may need some additional care and attention. Teams have a variety of options when it comes to dealing with these requests, but what we will commonly see is that teams use their historic velocity (Yesterday’s Weather) to predict how much work they can achieve during a Sprint. Provided the interruptions are fairly consistent from one sprint to the next this can work well.
The problem with this approach is that the interruptions remain hidden. People work on the interruption, then go back to the planned work.
One of the pillars in Scrum is transparency. We should ensure that we are transparent with the team, our Product Owner, and stakeholders as to what interruptions we faced during the Sprint. Therefore, we should make visible the interruptions so that they can be discussed in the Sprint Review. If we were to create new JIRA tickets for each interruption we could soon find ourselves in a messy situation, trying to understand which of the features interruptions are related to, and ensuring that there is an open epic to which the story can be assigned.
I have been suggesting to teams that they have an interrupt buffer added to each sprint at planning. When the unexpected work arrives whoever picks up the issue can add a comment/log work to the buffer in order to ensure that it’s documented and not forgotten when it comes to reviews. At the Sprint review and retrospective, we can examine the unplanned work completed by the team during the Sprint and address this with the stakeholders as needed.
The Scrum Patterns community have documented two pattern languages (organization and value stream) for implementing Scrum. The Illegitimus Non Interruptus (interrupt buffer) pattern suggests creating a buffer for unexpected work. This pattern limits the buffer size (amount of work which can be completed as part of this buffer) based upon historical data. It is intended to be used for the smaller trivial items, i.e. investigating a production incident (and potentially fixing it, if this can be done in a few hours total). For larger tasks, i.e. the bug has been investigated but will take days to resolve, a new Product Backlog Item is created and these go to the Product Owner who will prioritize the work, deciding if it should go into the backlog or added to the current Sprint (with something of equal size removed).
The pattern also describes some important rules. The buffer is of limited size based on historical data. All non-trivial work still goes via the Product Owner to evaluate the value of the work, and then prioritize it. And, if the buffer overflows (more items are added to the buffer than capacity was allocated) the Sprint is automatically aborted.
Aborting Sprints is something we have tended to avoid doing and is a longer discussion than I would like to add to this blog post. I constantly see teams over estimate what they will achieve during a Sprint, with work slipping over into additional Sprints. Therefore, for an initial implementation of the interruption buffer log I suggest that teams begin by just logging the unexpected work that they perform during a Sprint, so that they have some data with which they can start conversations.