Scrum for operations teams: planned work and interruptions

An operations team is never working only on what it planned. A disk fills, a certificate expires, a customer cannot log in. The Sprint begins on Monday with a clear goal, and by Wednesday half of it has been consumed by things nobody predicted. Teams in this position often decide that Scrum does not fit. It can, if the shape of the work is faced honestly.

Two kinds of demand

Planned work. Improvements with a goal: automating a manual deployment, upgrading a platform, reducing alert noise. It can be ordered, sized and finished. It is the kind of work Scrum was designed for.

Unplanned work. Incidents, requests and failures. It arrives at random, has urgency set by others and cannot be scheduled. Part of it is real emergency, and part is routine requests with a service expectation.

Most teams have both, in varying proportions. The proportion drives the choice of method.

What the sources say

The GOV.UK Service Manual speaks directly to this situation. Scrum, it says, is a good starting point for new agile teams building or enhancing a product or service. Teams running a live service with urgent requests may find sprints restrictive, and can switch to a flow-based method such as Kanban while keeping Scrum activities such as daily stand-ups, retrospectives and regular progress reviews.

The Scrum Guide does not carve out operations, but includes it. The Scrum Team is responsible for all product-related activities including maintenance and operation, and Scrum is used in domains with complex work beyond software. It also gives a way to handle disruption within a Sprint: the Sprint Goal is a commitment that gives flexibility in the exact work, and scope may be renegotiated with the Product Owner as more is learned, as long as nothing endangers the goal. The Guide allows the Product Owner to cancel a Sprint if the goal becomes obsolete.

The Kanban Guide offers the flow tools: controlling work in progress, managing item age and unblocking stalled work, and a service level expectation based on historical cycle time. Operations teams who answer requests often find them useful. See Scrum vs Kanban.

Three ways to organise

1. Scrum with reserved capacity. Plan the Sprint for the improvement work, and set aside a share of capacity for interrupts, based on history. If the team usually spends a third of its time on incidents, plan for two thirds. The Sprint Goal covers the planned part. Incidents are handled as they arise, and at the Review the team reports both. This works when the interrupt rate is moderate and fairly stable.

2. A flow method for everything. All work, planned and unplanned, goes through one board with limits on work in progress and rules for urgent items. There are no Sprints. The team keeps a regular retrospective and a regular review cadence. It works when most of the work is requests, with little planned improvement, or when interrupts are heavy and unpredictable.

3. A hybrid of two streams. Some teams separate the work: a small on-call rota deals with incidents and requests, while the rest of the team works in Sprints on improvements. The rota rotates, so that everyone shares the load, and the Sprint is protected. This works when the team is large enough to split. It adds a handover between the rota and the rest, and the rota's findings feed the backlog.

Whichever is chosen, the same thing applies: make the unplanned work visible, count it and learn from it.

Planning capacity with interrupts

The method in capacity planning in practice applies, with the step for the unplanned share made explicit.

1. Measure the share of time spent on unplanned work over the last six to eight Sprints.
2. Plan the next Sprint at the remainder, and be cautious.
3. Track the actual share each Sprint and adjust.
4. If the share keeps rising, treat it as a finding. Something is generating work that the team should remove.

This is where operations differs from feature teams: the best use of the planned time is often to reduce the unplanned. Automating a manual fix or removing a source of alerts shrinks next month's interrupts.

Incidents and the backlog

An incident is the start of a learning loop and not only a fire to put out. The standard practice in site reliability engineering is the postmortem, a written record of an incident, its impact, the actions taken, its root causes and the follow-up actions to prevent it from recurring. Without a formal process of learning, the source says, incidents may recur indefinitely. The practice is blameless: it studies how the system allowed the failure and not who made the mistake.

For a Scrum team, the follow-up actions become Product Backlog items, ordered like others. A Retrospective can review the incidents of the Sprint and ask whether the same cause recurs. And when the Sprint Review includes the number and kind of incidents next to the improvements delivered, the stakeholders see the whole picture. See DevOps and Scrum.

A worked example

This is an illustrative platform team of six running internal infrastructure for forty product teams. Over a quarter, 38 percent of its time goes on incidents and requests.

At first it plans Sprints at full capacity and misses most Sprint Goals. The Scrum Master brings the figures to the Retrospective. The team chooses the hybrid approach: one person is on rota each week for incidents and requests, and the other five work in two-week Sprints on improvements. Planned capacity is 85 percent of five people.

In the first Sprint the Sprint Goal is to automate certificate renewal. The rota person handles three incidents and eleven requests. At the Review the team shows the automated renewal working, and reports that the rota's incidents included two expiry failures, the kind the work would remove. Two follow-up items from the postmortems go into the backlog: better alerts on disk growth and a runbook update.

Over three months, unplanned work falls from 38 to 24 percent, partly because the improvements target the commonest incidents. Goal achievement rises from two of eight Sprints to six of eight.

Pitfalls

• Pretending interrupts do not exist. Full-capacity plans fail by design.
• Treating every request as urgent. Agree a service level expectation and classify.
• No time for improvement. If everything is interrupt, nothing improves.
• Heroics. Relying on one person who knows everything.
• Blame in postmortems. It stops people reporting.
• Counting incidents closed as success. The aim is fewer incidents.
• Cancelling Sprints for every emergency. Only cancel if the goal is obsolete, as the Guide says.

How to practise it

Count the share of your team's last four Sprints that went on unplanned work and plan the next Sprint at the remainder. Track it again afterwards. In the simulator the Impediment log and the Daily Scrum at step 3.2 deal with unplanned issues inside a Sprint, which is the same trade-off.