How should Product and Engineering plan for unplanned engineering work?

Plans often assume engineers can spend every available day on new Features. Production incidents, security fixes, customer support and rework then arrive as invisible interruptions. The resulting missed commitments can look like poor estimation, even when the real problem is that demand and capacity were never shown together.

Distinguish unpredictable timing from predictable demand

A specific incident may be unexpected, but a service with regular support and defects has a recurring demand pattern. Classify work by source, urgency and consequence without creating a burdensome timesheet. Look at recent weeks or months for interruption frequency, waiting and recovery effort, while recognising that rare severe incidents may not appear in the average. Product should see what this work displaces and why it matters to customers. Engineering should explain system risk and the effort required to restore safe operation.

Plan capacity using evidence and explicit rules

A team might reserve some capacity, rotate a support role, maintain an urgent lane or plan fewer Features. There is no universal percentage: the right allowance depends on service maturity, risk and observed demand. Agree what qualifies for immediate interruption, who can make that call and when Product must be informed. Keep operational obligations visible in the same planning conversation as product work. GOV.UK guidance supports regular reprioritisation based on evidence; Scrum explicitly treats the plan as adaptable as teams learn.

Replan together when the pattern changes

If urgent demand exceeds the allowance, do not ask engineers to absorb it silently. Engineering describes what happened, expected recovery and technical risk. Product revisits the order and scope of planned work and communicates revised expectations. For a major incident, authorised responders lead mitigation; Product helps manage customer and business priorities. Where a deadline cannot move, jointly decide which lower-value work to remove or escalate the conflict. AI may help classify tickets or summarise incident records, but the evidence and decisions must be checked by people who own the service.

Reduce the avoidable share of unplanned work

DORA guidance links continuous delivery capability with less rework and unplanned work, but that does not prove every team will see the same result. Review causes: fragile releases, noisy alerts, unclear ownership, delayed upgrades or repeated manual repairs. Set aside deliberate time for the most valuable systemic fix and monitor whether interruptions fall without hiding unresolved issues. Some unplanned work is inherent in running a service. The goal is a credible plan and a healthier system, not a promise of zero incidents.

Example

In a hypothetical payments team, several engineers are repeatedly pulled into failed settlement investigations. Product initially plans three new Features, while Engineering shows the recent interruption pattern and a risky manual reconciliation step. The team plans fewer Features, rotates an incident responder and funds a bounded reliability change. When an exceptional outage occurs, Engineering leads recovery and Product reprioritises the remaining Feature work. They review the allowance after the next operating cycle.

FAQs

• Should a team reserve a fixed percentage for unplanned work?

  Use a provisional allowance based on the team’s evidence and risk. Revisit it when demand or service conditions change.

• Does an incident belong in the product backlog?

  The response needs immediate operational ownership; follow-up fixes and prevention work should be visible alongside other product and system investments.

• Who tells stakeholders that planned work has moved?

  Product normally communicates the product priority and outcome change, using Engineering’s evidence about the interruption and revised feasibility.