Table of contents
Research context
This protocol asks how much of an offshore sprint goes to unplanned production support and what kind of work creates the load. The unit is one engineer-day in a sprint, allocated to planned delivery, unplanned support, or waiting. The study measures the share of time spent on interrupts, the source of each interrupt, and whether the work could have been planned. It does not evaluate the engineer's productivity.
Set the scope to one team, one sprint cadence, and one support policy. Record the on-call rotation, the ticket sources, and the definition of an incident at the start. If the support policy changes during the window, keep the earlier definition for the full sprint or analyze the change as a separate period. A new escalation rule can look like more incidents when it is only a different intake path.
Define the population as every engineer-day in the sprint for engineers assigned to the lane. The unit is the engineer-day, not the ticket, because one incident can consume several people for part of a day. A day split between planned and unplanned work is recorded as a share, not forced into one category. A holiday or a leave day is excluded and stated. Keep the allocation rule for every day.
Record the sprint, engineer, role, on-call status, and planned allocation. These strata matter because an on-call engineer is expected to absorb interrupts while a feature engineer is not. Include the days when the team had no on-call owner, because that absence is part of the finding. Test the allocation rule on two recent sprints before collection begins. Use one category list for the whole sample.
Define planned delivery as work that was in the sprint commitment at the start. Define unplanned support as work that arrived after the commitment and required action during the sprint. Define true incident as a production failure that affected customers or a critical internal service. Define avoidable support as a request that could have been planned, such as a configuration change or a data fix. Each definition needs an example and a boundary case.
Do not count a code review or a normal pull request comment as unplanned support. Do not count a scheduled deployment as an incident even when it happens outside core hours. A customer question that support answers without engineering is not an engineer interrupt. Record those exclusions so the rate is not inflated by ordinary collaboration. The unit is engineering time, not message volume.
For each engineer-day, capture the planned items, the interrupts, the time spent, and the source of each interrupt. Add the ticket id, the requester, the severity, and whether the work was repeatable. Record whether the interrupt was resolved on the same day or carried into the next. Keep the daily log with the sprint record so a second reviewer can rebuild the allocation. Use one log format for every engineer.
Practical application
Also capture the number of interrupts handled outside the engineer's working hours. These events matter because they consume recovery time even when the hours are not counted in the sprint. If the team uses a follow-the-sun rotation, record the handoff time and the next owner. A second reviewer should be able to see the load that the sprint report hides.
Draw the sample from the sprint board and the support queue rather than from a list of known incidents. Record the export date, the filters, the row count, and the selection rule. Include every sprint in the window and every engineer in the lane. If the team changed membership during the window, record the change and analyze it as a separate period. Do not drop a sprint because it looks unusual without stating why.
Collect the work log as it existed at the end of each sprint, not as it was reconstructed later. If an engineer updated the log a week after the sprint, note the delay. Do not infer unplanned work from a missed commitment alone, because the cause may be an estimate error. Note the collection date separately from the sprint date so the reader can see the age of the record. Keep the raw export with the analysis.
A useful additional measure is the share of interrupts that repeated the same root cause. A recurring data fix or a recurring certificate renewal is a planning gap, not an incident. Record the root cause and whether a permanent fix exists. That view helps the owner decide whether to fund a fix or accept the load. Show the repeat count beside the interrupt hours.
Report the number of engineer-days, the share of time on unplanned support, and the share on true incidents. Show the counts by sprint, role, and on-call status. Present the median interrupts per engineer-week and the share of interrupts that recurred. Use the same denominator for every rate and show the number of days with incomplete logs. Show the raw hours beside each share.
Inspect the heaviest days and describe the source without naming the engineer. A cluster after a release may point to a weak smoke test, while a cluster on one customer may point to a configuration problem. Compare the result with the on-call rotation and the sprint commitment. Report planned absence separately so it does not look like lost capacity.
A useful additional view is the time to acknowledge and the time to resolve an interrupt. A team that acknowledges fast but resolves slowly may have a triage problem rather than a capacity problem. Show the two times beside the volume. That view helps the owner decide whether to add people, improve the runbook, or change the intake rule. Keep the definitions stable across sprints.
Operating controls
The review should separate support that protects customers from support that compensates for a missing product feature. A manual data fix may be necessary, but if it happens every week the product needs a change. Record the reason and the owner. That split keeps the team from normalizing a permanent workaround as part of the sprint. Name the product owner for each recurring item.
The record cannot show whether the engineer could have prevented the interrupt or whether the customer was satisfied. It can show only the logged time, source, and resolution. A high interrupt share is not proof of poor planning, and a low share is not proof that support is healthy. The protocol also cannot capture work that the engineer did without logging it.
Support queues can omit requests made in chat, and sprint boards can hide work added after the planning meeting. An engineer may resolve an incident without opening a ticket. Record those gaps and their treatment instead of dropping them silently. If the same person is on call every sprint, note the rotation limitation and analyze that period separately. Keep the original queue export with the sample.
A useful check is whether the team can name the top three interrupt sources and the owner of each permanent fix. If the list is vague, the team is treating the load as weather rather than as work. Ask for the fix date and the evidence. That answer turns the review into a plan. A source without an owner will keep returning.
Give the result to the engineering lead and the product owner and ask them to choose one observable change. The change might be a planned support budget, a permanent fix for the top recurring cause, a better on-call rotation, or a stricter intake rule. Record the owner, the effective date, and the measure that will show whether the change worked. Avoid changing the sprint length and the support policy at the same time.
Repeat the protocol with the same definitions after the change and compare the same fields. If incident time fell but planned delivery did not rise, the team may be filling the gap with other work. If planned delivery rose but customer satisfaction fell, the support budget may be too small. Close the review when the owner accepts the finding and the next sprint is scheduled.
The final view is the customer's experience during the sprint. A fast internal resolution is not enough if the customer waited for a workaround. Record the customer-facing time and the number of updates. That context helps the owner see the cost of unplanned work beyond the engineer's hours. Keep the customer timeline with the sprint record.
Sources
Frequently asked questions
What should happen first?
Begin with a bounded ticket, approved access, explicit acceptance evidence, and a named reviewer.
Who approves production changes?
The client's technical owner keeps final merge and release authority.
Related research
What share of offshore pull requests need a second review round?