Interrupts happen. In computing, an operating system has to be able to handle interrupts or the machine will crash. It’s the same with Sprints. The key to handling interruptions is to expect them.
One of the core ideas in Scrum is that the Team is not interrupted during a Sprint. All the work that needs to be done in a Sprint should be laid out and prioritized in the Sprint Backlog during Sprint Planning.
That’s the ideal. However, there are often times, when interruptions are unavoidable. Real time feedback can be essential for creating a quality product but it needs to be regulated to protect the Team from getting mixed messages and slowed down. In a perfect world, that feedback would be incorporated into the Product Backlog for future Sprints, but there are times when it simply isn’t possible to wait.
Here’s what to do: First, all requests for new or found work have to go through the Product Owner. The Product Owner should examine how many unplanned tasks come into a Sprint and then create a buffer that accounts for them. For example, if a team typically has a velocity of 200 points, but routinely gets 50 points worth of interruptions, the Product Owner should only allow the team to take in 150 points in any one Sprint and have a 50 point buffer.
Second, when an unplanned task surfaces the Product Owner orders it in the buffer according to business value. The most important thing is to take a deep breath and realize that many requests can be put off to the next Sprint, but the critical interrupts that cannot wait go into the buffer.
The Interrupt Pattern is a tool that protects the Team from unreasonable exceptions. If it is obvious the interrupt buffer is going to overflow the Product Owner should immediately activate the Scrum Emergency Procedure, aborting the Sprint.
The post Interrupt Pattern appeared first on Scrum Inc..