The organization

Protecting the Sprint from interruptions

A team that serves many people is interrupted by all of them. Five patterns from A Scrum Book organize the response: an interruption budget set in advance, an emergency procedure when the Sprint goes off course, a phone reserved for critical cases, a velocity stabilized before any improvement and a defined place for managers.

"Just a little poster"

The communications department of a town hall has four people: a graphic designer, a writer, a webmaster and a photographer. It works in Sprints, fixed-length periods that last two weeks here, and each Sprint has a goal, the Sprint Goal. The current one is to send the March issue of the town magazine to the printer.

On Monday, the deputy mayor for culture puts his head around the door: "I just need a poster for Saturday's concert. It's an hour's work." On Tuesday, the town manager asks for a slide show for Thursday's council meeting. On Wednesday, the swimming pool closes because of a breakdown, and signs and an online notice are needed. Each request, taken alone, is reasonable. On the Friday of the second week, the magazine is not ready.

Illegitimus Non Interruptus: a budget for the unexpected

A Scrum Book (2019) describes Scrum as a set of patterns: each one sets out a recurring problem, the forces at play and a solution drawn from experience. The Illegitimus Non Interruptus pattern, whose name in mock Latin evokes illegitimate interruptions, carries one star: the authors see in it the core of a good solution, without ruling out that others exist.

The problem. Changes of priority and incidents interrupt the work during the Sprint. Repeated, these interruptions make Sprints fail one after another and render delivery dates unworkable.

The forces. The team is a shared resource serving many stakeholders. The book sees this as a case of the "tragedy of the commons", described by the ecologist Garrett Hardin in 1968: everyone draws on the resource according to their immediate interest, and together they end up exhausting it. A Product Owner who is too weak (the Product Owner is the person who orders the list of what needs to be built) lets competing priorities reach the team. Yet not all interruptions can be removed, because the book insists that the team fix its own product's defects.

The solution. The team explicitly sets aside time for interruptions and accepts no more unplanned work than that budget. Three rules are enough.

• The team sizes a buffer from its history. In the book's example, a team whose average velocity is 60 points (velocity is the amount of work finished per Sprint, estimated in points, a relative unit specific to the team) and a third of whose work arrives without warning sets aside 20 points.
• Any request that is not trivial goes through the Product Owner, who turns some down, postpones many to a later Sprint and places the rare critical requests in the buffer.
• If the buffer overflows, the Sprint is automatically stopped and replanned, and the Product Owner warns management that dates will slip.

These rules need management's prior agreement. According to the authors, they push requesters to discipline themselves, because nobody wants to be the one who makes the Sprint fail. The buffer then rarely fills, and the team can shrink it over the Sprints.

The 2020 Scrum Guide makes no provision for a buffer. It states that "A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint." The pattern's automatic stop can be read as a decision the Product Owner announces in advance, but this rule belongs to the book, not to the Guide.

Emergency Procedure: when the Sprint goes off course

The Emergency Procedure pattern, also called Stop the Line, carries no star: for the authors it is one good solution among others.

The problem. Difficulties arise during the Sprint, whether new requirements, a technical obstacle or the loss of a key person. Halfway through, the chart of remaining work shows that the Sprint Goal will not be reached at the current pace. Waiting until the end to find out loses the whole Sprint.

The forces. Reacting quickly means making problems visible early. Yet teams, especially young ones, do not like stopping the work and exposing themselves to criticism. The book recalls the story of the NUMMI plant, which Toyota ran with General Motors in California: workers did not dare pull the cord that signals a problem and can stop the line, and the Japanese managers pulled it themselves to show that this reluctance was the main obstacle. The Lean corpus article on the andon (in French) describes this device.

The solution. Like a pilot facing a failure, the team applies without delay a procedure prepared in advance. The Scrum Master (the person who helps the team practice Scrum well) makes sure it is triggered, preferably before the middle of the Sprint. The steps follow one another, and the team does no more than necessary:

• change the way the work is done;
• get help, usually by handing part of the work to someone else;
• reduce the scope;
• stop the Sprint and replan;
• and inform management of the consequences for the dates.

Only the Product Owner decides to stop a Sprint, as in the Scrum Guide. The Guide also accepts that "Scope may be clarified and renegotiated with the Product Owner as more is learned", which corresponds to the third step. Cancellation remains reserved there for the case where the Sprint Goal has become obsolete, whereas the book also makes it a signal sent to the organization.

The authors reserve this pattern for disciplined teams. A team that resorts to it more than once every four Sprints without improving has a deeper problem. They advise beginner teams to see the Sprint through, then analyze its failure at the retrospective, the meeting where the team examines how it works.

Small Red Phone: reaching key people for certain

A protected team can also find itself stuck for lack of an answer. The Small Red Phone pattern (no star) deals with this case.

The problem. Scrum relies on fast feedback. If the Product Owner or the Scrum Master cannot be reached at the moment the team discovers, for example, that it has misunderstood an item, a few hours' wait can derail it.

The forces. These people often work elsewhere, rightly, on the team's behalf. Giving out their usual number would expose them to constant disturbance.

The solution. Each key person receives a red phone, with its own number known to the team and reserved for critical situations. A small, humorous forfeit discourages abuse, and every call is discussed again at the retrospective. Today, a dedicated number or messaging channel plays the same role.

The book itself limits the pattern's scope. This is communication by interruption, inferior to the meeting place described in the article Stable, co-located teams. If the phone rings often, it is making up for a failing organization, and it will not replace proximity in the long run.

Kaizen Pulse: stabilize before improving

Interruptions make velocity vary from one Sprint to the next. Yet the buffer is calculated from history, and an improvement can only be judged against a baseline. The Kaizen Pulse pattern (one star) addresses this point. Kaizen is Japanese for continuous improvement.

The problem. It is hard to show an improvement from one Sprint to the next, because a reliable baseline takes time and any single measurement is subject to the vagaries of the process.

The forces. If velocity varies a lot, you cannot tell whether a change helped or hurt. If several changes are introduced together, you do not know which one mattered. People also need time to absorb a change and make it a habit.

The solution. The team alternates periods of controlled velocity with bursts of improvement. It first establishes a stable baseline, with variations kept within a 20% margin as a benchmark. It then introduces a single improvement, practices it until it becomes routine, and judges its effect over several Sprints before keeping or dropping it.

The book lists management interference in production among the most frequent causes of variation. Protecting the Sprint is therefore one of the first improvements to make. The article on the retrospective and continuous improvement covers this pattern in detail.

Involve the Managers: a place for managers

Many interruptions come from managers who want to help. The Involve the Managers pattern (one star) looks for a useful place for them.

The problem. Scrum has no provision for managers: the Developers manage themselves and the Product Owner decides about the product. The managers already in place look for their role, and some meddle in the team's work, to the point of telling the Developers how to do it.

The forces. Managers hold powers that Scrum's roles lack: committing the company legally, reorganizing it or managing a contract that concerns several products. Teams practice improvement in small steps, but an organization sometimes needs radical change (kaikaku), for example discontinuing a product, which a Product Owner will not decide against their own product.

The solution. The organization keeps a slimmed-down management function, able to launch and take responsibility for radical changes, and to deal with impediments too heavy for the Scrum Master or the Product Owner. Teams manage themselves. Managers meet them at a regular appointment, the MetaScrum, usually through the Product Owners, and take part in no other Scrum event. The article Scaling up describes this meeting.

Managers thus have a legitimate channel for influencing priorities, which removes the reason for interrupting mid-Sprint. The Scrum Guide does not mention managers and states that "For Product Owners to succeed, the entire organization must respect their decisions."

Limits and pitfalls

The buffer can become a second list through which everything ends up passing, especially if its size is never reviewed. It only works if the threat of stopping the Sprint is credible, and therefore if management has genuinely accepted the rule. The book itself estimates that overrunning the buffer costs at least half the velocity: stopping is expensive and must not become a habit.

The word "illegitimate" can mislead. An interruption is sometimes the most useful thing the team can do, for example when a serious defect affects users. Sorting belongs to the Product Owner, and the article on the Definition of Done and quality explains why defects are fixed without waiting.

These patterns rest on their authors' experience and on company stories. The book relies on no independent measurement to say what buffer size is right or how often the emergency procedure pays off. The article Criticism and the state of the evidence returns to the status of these recommendations.