In a perfect world, a Scrum team should be allowed to execute their sprint without being interrupted, and all changes or new requirements should be addressed at dedicated Scrum events.
While Scrum teams should aim for a world of no sprint interruptions, it’s not the reality most teams face on daily basis. Customer usually do request new functionalities, users do discover critical defects, etc. So, what can the teams do when a change can’t be kept out of their sprints?
Introducing a buffer
One of the most common strategies to deal with such ad-hoc changes is introducing a buffer (a room for some amount of unplanned work) to team’s sprint plans. It’s worth mentioning, however, that the buffer should be used only for the unplanned work that wasn’t known when sprint was planned in, it shouldn’t not be an excuse for bad planning itself.
There are two ways to introduce the buffer into the sprint. First, the team can plan in a virtual backlog item of a given size that will count towards team’s velocity. Each time a new task is added to the sprint, its size is subtracted from the buffer. Second, the team can plan less work that their usual sprint velocity. During the sprint, the team just takes on new tasks, and the difference between average velocity and planned velocity acts as an implicit buffer.
Tracking
Regardless of how exactly the buffer is implemented its usage must be carefully tracked. It’s critical because it allows for making reasonable decisions about the use of the buffer and influences sprint execution.
For example, if 30% through the calendar time of the sprint the team has already used 80% of their buffer, the Product Owner should be very strict about letting further changes into the sprint. Alternatively, if the team has only used 20% of the buffer, the Product Owner could be a little more permissive in allowing a change into the sprint (assuming the team is on track to meet its sprint goal).
A simple way to visualize a usage of the buffer over time is to create a graph similar to a burn-up chart, like the one below:
Downsides
Interrupt Buffer is a simple solution, but it comes with a price. Obviously, it will take longer to deliver the road-map (planned work), proportionally to the buffer size. In addition, in many cases a need for having a buffer comes from a dysfunctional organization or a technical debt – buffers somehow hide these types of problems and may discourage the team from addressing root causes of the problems.
