Even though software engineering sprints are supposed to be uninterruptable to maximize focus time for engineers, I think there are two cases where you should break the sprint:
- An incident or outage needing the whole team
- A large and unexpected business opportunity
In each case, it is worth considering what would happen if you did not break the sprint.
During an incident, your software is not functioning and thus delivering no value to customers. This state of operations imperils the company’s ability to exist and must be addressed promptly. It is much better to have the company up and running with a slight delay in the delivery of the sprint’s features than the converse.
The second case is a bit tricker and hinges on what it means to be both large and unexpected. Large means that the opportunity is so big that if you were to plan the sprint today, this would be the number one priority for the team. Unexpected means it was unreasonable to have known about this opportunity while planning the sprint. It might mean responding to a current event or a competitor’s misstep. Even at early-stage startups, your target should be at most one such interruption per quarter.
Why should you only interrupt a sprint for unexpected business opportunities? Engineers need uninterrupted focus time to do their best work. It takes time for an engineer to research a problem, put the opportunity into code, and test the solution. This time is why sprints are longer than a day. If the team is always worried that their work might be interrupted it will be harder for them to do the deep work needed.
Interruptions also make it easier for the counterparties to software engineering to believe they can change things without cost – which is false. Every place I’ve ever worked has had too few engineers for the opportunities available. Thus it is imperative to direct their work to the most important activities.