Scrum and interruptions (urgent bugs, requests)

Question

Does Scrum take into account interruptions? For example:

• urgent bugs from production environment
• requests from other teams

This is very important in real development process.

In practice of Scrum teams these interruptions often just happen and disrupt the Sprint. Or Scrum teams just reserve 20%-30% of a Sprint for such interruptions, which drastically decreases the team's performance (and without guaranteeing that the reserved time will be enough for handling the interruptions and successfully completing the Sprint).

Answer 1

Does Scrum take into account interruptions?

Scrum does not. The Scrum team does.

Scrum teams are self-organized and plan their own work. If part of that work consists of fixing urgent bugs from production or handling requests from other teams, then the team needs to find a way to organize around that, how exactly depends on the context:

• they might introduce some slack into the process to handle these things (some time percentage of the sprint, or taking in less stories into the sprint);
• they might have a dedicated person (or team) handling these things (by rotation each sprint, for example) so that the rest of the Scrum team can focus on the Sprint goals;
• they might decrease the sprint length and then focus only on the sprint knowing that next sprint they can work on just those types of tasks (might apply to other requests, not when the production environment is in trouble);
• if things seem more like "operational" in nature and not "development", the team can even decide to give up on sprints and just do something like Kanban with some selected cadence for other practices you want to keep, like review and retrospective.
• etc.

Any kind of work involves planned and unplanned activities. This does not change with Scrum. It's the team's responsibility to figure out how to deal with the interruptions and keep delivering value with their development.

Answer 2

TL;DR

The Scrum framework certainly addresses capacity planning and scheduling, although it's not prescriptive about how the Scrum Team should manage the issues you describe. The implementation details are left as emergent properties of the framework's inspection and adaptation cycles.

From a purely practical perspective, you need to reduce your planned capacity to reflect the amount of work the Scrum Team is currently able to do each Sprint. The team should then continuously adapt its processes to reduce production problems and avoid work unrelated to its Sprint Goals.

Analysis and Recommendations

Scrum Theory says (emphasis mine):

Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed....Scrum employs an iterative, incremental approach to optimize predictability and to control risk.

What this means is that Scrum optimizes for predictability rather than high rates of utilization or throughput. Scrum doesn't increase your team's capacity to do work; it simply provides a framework for creating a predictable development/delivery cadence based on empirical evidence of how much work the team can get done within a typical iteration.

The Scrum Team is expected to inspect-and-adapt. This can take many forms, including:

1. Improving tools and processes to avoid deploying bugs to production.
2. Reducing planned capacity for each Sprint until you can predictably deliver your Sprint Goals most of the time.
3. Managing interruptions and change requests by educating other parts of the organization on the cadence of framework events such as Backlog Refinement, Sprint Planning, and Sprint Reviews.
4. Deferring less-urgent issues to the Product Backlog, where the Product Owner can influence when the issues will come into scope in a future Sprint.

When process problems are outside the direct control of the Scrum Team, the Scrum Values still require that:

The Scrum Team and its stakeholders are open about the work and the challenges...The Scrum Team members have the courage to do the right thing, to work on tough problems.

Pragmatically, this includes making issues with code quality, tooling, infrastructure, or organizational issues visible and transparent to all the stakeholders. Senior management ultimately drives company culture and budget, so they have ownership of all problems that can't be resolved by an empowered and self-managing team.

Answer 3

Scrum does address such problems through Inspection & Adaptation.

If your team is wasting a % on repetitive work, it should come up at the end of the sprint as a source of waste. This source of waste needs to be discussed by the team (potentially during the retrospective) and then the team might naturally come up with actions and alternatives that could address such waste.

Examples:

---

Scenario #1: The team is constantly interrupted to assist on production issues.

Addressing waste #1: Production is always priority. While the team addresses the solution, the team must also understand why the problem happened and what the team will do so that these problems will be mitigated. It's not about clean up the Production backlog from night to day. In 'real development process' projects, that's oftentimes unrealistic. What is realistic is to spare some capacity to address some production issue, after all it's a matter of dedicating time to address the root cause of a problem or keep wasting times with workarounds.

---

Scenario #2: the team is constantly interrupted with requests to help other teams.

Addressing waste #2: The team(s) should do some actual planning on knowledge sharing, taking advantage of each problem as a learning opportunity. It can be done in several different ways, either by doing pair programming, recorded training sessions, playback sessions, expanding documentations, you name it.

---

The bottomline: The team should really take the most of Inspection and Adaptation promoted by Scrum.

Answer 4

The first question is how frequent and impactful are these interruptions. The 2020 revision of the Scrum Guide refers to the Sprint as "the heartbeat of Scrum". If your team is highly interrupt-driven and cannot regularly complete the Sprint and achieve the Sprint Goal, then perhaps Scrum is not an appropriate framework for your team. It would help if you looked toward approaches that are more tolerant of interruption. This doesn't mean that you can't take lessons from Scrum, but using Scrum as defined in the Scrum Guide may not be the best option.

Assuming that you determine that Scrum is appropriate, Scrum is based on empiricism. The experiences can guide the team to determine how much capacity they have for planned work while ensuring that they have room for unplanned interruptions that normally happen. The frequent Sprint Retrospective can help find root causes for these interruptions, and a culture of continuous improvement can lead to an overall reduction in interruptions.

Specifically, the two interruptions mentioned in the question - urgent production bugs and requests from other teams - have solutions. There are methods to prevent and detect bugs earlier in the development process, preventing them from reaching production. The appropriate level of Product Backlog management and frameworks for coordinating across teams and products can help manage requests from other teams. Specific problems can come out in Sprint Retrospectives. The team can run experiments over a small number of Sprints to find adjustments to their way of working that reduces or even eliminates these interruptions.

Answer 5

If you really have as much as 30% on-demand work then your team might benefit from a Scrumban style approach. Prioritise your work on a board, with priority "buckets" taking the place of sprints. The team should adopt a pull-system with work-in-progress limits.

Certainly no system can eliminate the ill effects of context switching and unexpected interruptions. The best you can do is make the issues visible.

Answer 6

On top of what the previous commenter said that exactly The Scrum team does (plan time for bugfixing and tracking the regression), I would note that not all the bugs are blockers to deliver the iteration and prioritizing them is the key - actually, the issues just tell that the product is alive and it keeps going.

Collaborating with

• the focus group from Customer team
• with business analysts (who understand the priorities for the E2E process - e.g. like completing the order submission for the 'sales process' with all corrected calculations, but without performance optimization)
• with UX team on triaging the defects and setting the priorities solves the issue.

Moreover, there are practices and dev leads personal experience, open-source and proprietary tools, developed to increase and maintain code quality, which goes with Scrum/ Scrum-like approaches. Applying them from iteration to iteration (or only in most important moments) it will decrease the percentage of defects you get in the sprint.