How do you handle an urgent mid-sprint feature request?

WHAT THIS TESTS: This question tests your discipline and understanding of the Scrum framework, not your willingness to be a "team player" by saying yes. The interviewer is checking if you know the specific roles of the Developer and Product Owner, the importance of the Sprint Goal, and how to protect the team's focus and the integrity of the process while still being a good partner to the business.

A GOOD ANSWER COVERS: A strong answer walks through the formal Scrum process in four steps. First, acknowledge the stakeholder's request but immediately redirect them to the Product Owner, explaining that the PO is responsible for prioritizing all work. Second, state that the PO will then evaluate the new request's business value against the current Sprint Goal and the overall Product Backlog. Third, describe the possible outcomes. The most common is that the work is added to the Product Backlog for a future sprint. Fourth, explain the exception: if the work is critical, the PO can negotiate with the Developers to swap out an existing Sprint Backlog item of comparable effort, but only if the change does not endanger the Sprint Goal. In an extreme case, the PO can cancel the sprint, but this is a rare and disruptive last resort.

COMMON WRONG ANSWERS: The biggest red flag is saying, "I'd do it if it's small." This introduces untracked "shadow work," disrespects the Product Owner's role, and invalidates the sprint commitment. Another poor answer is simply telling the stakeholder "no." This is confrontational and misses the opportunity to guide them to the correct process. Finally, saying "I'd ask my manager" is a red flag, as it deflects responsibility; in Scrum, the team is self-managing and the correct channel is the Product Owner.

LIKELY FOLLOW-UPS: Be prepared for "What if the stakeholder is the CEO?" (The process is the same; it exists to provide transparency for everyone, including leadership). Also, "What if the change does endanger the Sprint Goal?" (Then the only options are to defer the work or for the PO to cancel the sprint; a swap is not possible). Finally, "What if the PO is on vacation?" (The work should be made visible on the Product Backlog for the PO to review upon return; for extreme urgency, the Scrum Master can help facilitate communication).

ONE CONCRETE EXAMPLE: Last quarter, our marketing lead needed an urgent change to a tracking pixel for a new $500k ad campaign launching in two days. The sprint goal was about user profile completion. I directed her to our PO. The PO immediately saw the urgency. She worked with the dev team, and we identified a low-priority bug fix in the sprint that was estimated at 3 story points. The pixel change was also estimated at 3 points. Since adding the pixel didn't compromise the user profile goal, we swapped the work. The PO communicated this change to all stakeholders. The sprint was successful, and the campaign launched on time.