What is the best way to handle 'Emergency Support' tickets during an active Sprint?

All answers to this question.

The "Interrupt Pattern" is a classic Scrum challenge. Most successful teams use the "Capacity Buffer" method. If your team historically spends 20% of their time on bugs, only plan for 80% of your total velocity during Sprint Planning. If no bugs appear, you pull from the top of the backlog. Another option is the "Batman" or "Firefighter" role—one team member is rotated each Sprint to handle all interruptions. They have zero points assigned in the Sprint. This keeps the rest of the team in a "Flow State." If the emergency work is so massive that it threatens the Sprint Goal, the Scrum Master must discuss an early Sprint termination with the Product Owner.

   Answered 2025-09-12 by Patricia Williams

If we have a dedicated "Firefighter," doesn't that create a "Silo" where only one person knows how to fix production issues, leading to a "Bus Factor" risk?

   Answered 2025-09-14 by Susan Taylor

• That’s why the role must be "Rotated," Susan. Every Sprint, a different person takes the "Firefighter" vest. This actually helps with "Knowledge Sharing" across the entire codebase. Over a few months, everyone becomes familiar with the common failure points in production. It’s a great way to build a "T-shaped" skill set within the team. While it might feel slower at first because a junior might take longer to fix a bug than a senior, the long-term resilience of the team increases significantly as the "Silos" are broken down.

     Commented 2025-09-16 by Christopher Davis

We moved our support work to a "Kanban" board and kept the development in "Scrum." This "Scrumban" approach gave us the flexibility we needed for a 24/7 app.

   Answered 2025-09-18 by Jennifer Harris

• Totally agree. Scrumban is perfect for teams with high variability. David, try the "Rotation" method first; it’s the easiest way to preserve the Scrum structure.

     Commented 2025-09-20 by David Carter