In a perfect world, a sprint would be disruption-free. No owner changes. No urgent new functionalities. And no defects. In the real world, Scrum teams deal with interruptions or disruptions during most of their sprints. How they handle them can mean the difference between meeting critical deadlines and throwing the sprint completely off.

A question we hear a lot, typically asked by someone who wants something right now, is “if you’re agile, shouldn’t we just take care of whatever issues come up as they come up?” While sprint flexibility allows for change, it isn’t productive for a team to simply drop everything they’re working on to deal with individual questions or complaints. As with most things in life, they’d never get anything done.

How to Handle Sprint Interruptions

Every sprint is different, so it makes sense every sprint interruptions is unique as well. So instead of trying to tackle every possible interruption that might occur, it’s good to have some guidelines in place that govern how sprints are run. Here’s what we like to do to plan for and handle interruptions when they occur.

  • Create upfront rules. When it comes to sprints, flexibility and hard rules can work together. Before starting a sprint, we like to talk about everything that could potentially disrupt it. Together with the owners and engineering team, we create rules that focus on doing the minimal fix required to keep the project on track.
  • Limit immediacy to strict outages. If an interruption has no workaround, is completely unreachable or broken, or is a critical function of the app, we immediately handle it.
  • Minimize fixes. We typically don’t do full fixes after a disruption. If there’s a manual workaround, we do that. For instance, we had a project where some leads hadn’t made their way into the database. A good, quick solution would be to ask someone to manually enter them until we deal with the problem in the next sprint. If it can’t be done manually, we still don’t transition to doing a full fix. Instead, we’d just write a cron job with a little script that moves the leads into the right place—sort of like a hack.

Agile Sprint Planning

The goal is to use a workaround when bugs come and use that workaround until the next sprint planning. So, when a disruption happens we:

  • Write a good story.
  • Start our grooming process.
  • Go through refinement, figuring out what caused the bug, and writing unit test coverage.

We’ve learned that what generally happens when these outages come is no one writes really quality code, no one searches for the root cause, and no one really fixes anything so the same disruption doesn’t happen again. You instead end up just putting in something that’s substandard. It’s a Band-Aid solution that’s inefficient in the long-term. We prefer to go through our entire process so the problem gets fixed afterward in a good way.

Mitigate Effects of Sprint Disruptions

When you plan for disruptions ahead of time and put solid rules in place on how they’ll be dealt with, you set the stage for defeating the chaos that often accompanies them. A narrow focus, setting clear goals, and laying out specifics for how to handle interruptions keeps everyone and everything perfectly aligned to meet commitments and keep a project moving forward. Ready to learn more about managing sprint disruptions or how Zibtek’s sprint planning process helps you get the most out of your software? Contact us online today or call us at +1 (801) 895-2894 to schedule a consultation.