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

WHAT THIS TESTS: This question tests your understanding of core Scrum principles, not just your willingness to be helpful. The interviewer is looking for your ability to uphold the framework to protect the team's focus, predictability, and the integrity of the Sprint Goal. It's a test of process discipline, communication skills, and your understanding of the distinct roles of the Developer and the Product Owner.

A GOOD ANSWER COVERS: First, as a Developer, you do not accept the work. You listen to the stakeholder to understand the context, then politely redirect them to the Product Owner (PO). The PO is the single point of contact for all new work and is solely responsible for managing the Product Backlog.

Second, you explain that the PO will work with the stakeholder to understand the request's value and priority. The PO will then add it to the Product Backlog and order it appropriately.

Third, you articulate that the Sprint Goal is immutable for the duration of the Sprint. The Scrum Guide is explicit: "No changes are made that would endanger the Sprint Goal." While the Sprint Backlog can be negotiated with the PO as more is learned, the overall goal is fixed.

Finally, for a truly business-critical emergency, the PO has the authority to cancel the Sprint. This is a rare, high-cost decision. The Scrum Team would then immediately hold a new Sprint Planning meeting to create a new Sprint Backlog that addresses the new reality. A less disruptive option is for the PO to negotiate with the Developers to swap an item of equal or greater size from the Sprint Backlog, but only if this does not compromise the Sprint Goal.

COMMON WRONG ANSWERS: "I'll just do it." This is the biggest red flag. It bypasses the PO, invalidates the sprint plan, introduces un-tracked work, and destroys transparency and trust.

"Tell them to create a ticket for the next sprint." This is dismissive and usurps the PO's authority to prioritize. The request might be genuinely urgent, and it's the PO's job, not the developer's, to make that determination.

"I'll ask my manager or tech lead." This signals a misunderstanding of Scrum roles, reverting to a traditional command-and-control structure. The PO is the correct channel according to the Scrum framework.

LIKELY FOLLOW-UPS: "What if the stakeholder is the CEO?" The process remains the same. The value of Scrum is making the trade-offs of such requests explicit. You respectfully explain the process and its value to the CEO and direct them to the PO, who can discuss the impact on committed work.

"What if the Product Owner is on vacation?" A mature team would consult the Scrum Master for guidance. The team might collectively decide based on the established Product Goal, document the decision transparently, and sync with the PO upon their return. The work doesn't stop, but the process is respected.

ONE CONCRETE EXAMPLE: "A stakeholder from sales needs a new demo feature for a client meeting in two days. I would say, 'I understand the urgency. To ensure we handle this correctly and assess its impact on our sprint goal of launching the new dashboard, please connect with our Product Owner, Alex. Alex manages all priorities and can determine the best path forward, whether it's a trade-off in this sprint or a fast-track for the next.' This respects the stakeholder while reinforcing the correct process."