Interrupt Work

Interrupt Work image
Interrupt work is unplanned work a team has to pick up during a sprint that sits outside the stories it committed to, such as production fixes, urgent support requests and stabilising the last release. It is often measured as the hours or percentage of sprint capacity it consumes, and is sometimes called unplanned work.

Why it matters: High interrupt work is a sign that learning is happening after delivery rather than before it. It quietly takes time away from planned work, and testing is often the first activity squeezed to protect scope. Tracking it alongside lead time shows the gap between a team's delivery cycle on paper and the time it really takes for work to become stable in production.

In practice: Teams log the hours spent on anything outside the sprint's planned stories and review the total at the end of each sprint. They also look for production stabilisation from the previous release spilling into the next iteration. Comparing interrupt work with lead time from ready for development to stable in production helps show where quality is being deferred rather than built in.

Examples:

  • A team finds that interrupt work averaged 32 percent of sprint capacity over a quarter.
  • A feature is marked done on day 10 of a sprint, released on day 15, then needs fixing and retesting on days 23 to 25 after a production issue.
  • A tester notices regression testing being cut each sprint to make room for urgent fixes from the previous release.

Common pitfalls:

  • Absorbing interrupt work without recording it, so the sprint looks predictable while the team is overloaded.
  • Treating interrupt work as unavoidable noise rather than a signal about assumptions and quality earlier in delivery.

How do you measure interrupt work? Record the hours spent on work outside the committed stories each sprint, then divide by total sprint capacity to see the share it takes.

Is interrupt work always bad? No. Some unplanned work is normal, but a high or rising share usually means problems are being found late and should prompt a look at refinement, testing and release practices.
Explore MoT
Test Forward 2027 · Software Quality in the age of AI image
Tue, 19 Jan 2027
Test Forward is one afternoon at Station F with the QA and engineering people closing that gap in their own teams.
A tester’s role in continuous quality  image
Build quality into every step of the software lifecycle with the whole team involved
This Week in Quality image
Debrief the week in Quality via a community radio show hosted by Simon Tomes and members of the community
Subscribe to our newsletter