How do you handle an urgent, mid-sprint stakeholder request?

WHAT THIS TESTS: This is a behavioral question disguised as a process question. It tests your ability to uphold team commitments, respect established roles (especially the Product Owner's authority), and manage stakeholder relationships professionally. Interviewers want to see if you can protect the team's focus and the integrity of the sprint without alienating business partners. They are evaluating your pragmatism and communication skills, not just your rote knowledge of the Scrum Guide.

A GOOD ANSWER COVERS: A strong answer has four parts. First, listen and acknowledge. Show the stakeholder you understand their request is urgent and important to them. Second, explain the process. Briefly state that all new work is prioritized by the Product Owner to ensure the team works on the most valuable items. Third, redirect. Connect the stakeholder with the Product Owner. Offer to facilitate the introduction or help them articulate the user story and its business value. Fourth, explain the trade-offs. Mention that the PO will weigh this new request against the current Sprint Goal. If it's a true emergency, the PO has the authority to work with the team to potentially cancel and replan the sprint, but this is a rare and significant decision.

COMMON WRONG ANSWERS: The most common red flag is saying "yes" immediately. This shows you're willing to let the team's plan be derailed, it disrespects the Product Owner's role, and it hides the true cost of the interruption. Another red flag is being overly rigid or dismissive, simply saying "No, we're in a sprint." This damages relationships and makes the engineering team seem like a black box. A junior answer might involve asking the Scrum Master to handle it, which is passing the buck; a senior engineer should be able to handle this initial conversation.

LIKELY FOLLOW-UPS: Be prepared for "What if the Product Owner is on vacation?" (The answer involves consulting their delegate or, in a true crisis, making a collective decision with the team and leadership, understanding the risks). Another follow-up is "What if the stakeholder is the CEO?" (The process is the same. It exists to provide transparency for leadership. You still redirect to the PO, emphasizing that this ensures their high-priority request is properly evaluated against other company goals).

ONE CONCRETE EXAMPLE: "A VP of Sales once asked me mid-sprint to add a special reporting feature for a deal closing in a week. I told her, 'I understand this is critical. Our process for new requests is to run them by our Product Owner, Sarah, who manages our priorities. Let's get 15 minutes on her calendar now. I'll join and help explain the technical side. She can determine if we should tackle this now, which might mean swapping out another feature.' This respected the VP's urgency while upholding our process. The PO ended up working with a data analyst to get a one-off report, solving the need without disrupting the sprint."