A mid-sprint task jeopardizes the Sprint Goal. What now?

WHAT THIS TESTS: This question tests your practical application of Scrum's core principles, specifically adaptation in the face of new information. The interviewer is looking for evidence that you prioritize the Sprint Goal above all else, understand the distinct roles of the Developers and the Product Owner, and use Scrum events (like the Daily Scrum) for their intended purpose: inspection and adaptation. It's not about blame; it's about a mature, collaborative response to an inevitable part of complex work.

A GOOD ANSWER COVERS: A strong answer follows a clear, collaborative sequence. First, immediately create transparency. The developer who discovers the issue should raise it to the rest of the team, ideally no later than the next Daily Scrum. Second, the Developers as a unit assess the impact on the Sprint Goal. They determine if the goal is still achievable, perhaps with a modified plan. Third, the Developers collaborate with the Product Owner. They present the situation and options. This is a negotiation about the scope of the Sprint Backlog, not the Sprint Goal itself. The Product Owner is the only one who can decide which work items to drop or modify. Fourth, the team adapts the Sprint Backlog based on the negotiation, creating a new, realistic plan to meet the Sprint Goal.

COMMON WRONG ANSWERS: A major red flag is suggesting the team should just "work harder" or work nights and weekends. This indicates a misunderstanding of sustainable pace, a key agile principle. Another wrong answer is to unilaterally drop tasks without consulting the Product Owner, which usurps their authority over the backlog's scope. Suggesting to cut quality ("we'll skip writing tests for this") is a critical failure, as it creates technical debt and violates the Definition of Done. Finally, waiting for the Sprint Retrospective to discuss the problem is too late; the opportunity to adapt and save the Sprint has been lost.

LIKELY FOLLOW-UPS: "What if the Product Owner is unavailable or insists that all original scope must be completed?" This tests your negotiation skills and understanding of the Scrum Master's role in coaching the PO and protecting the team. "What if the Sprint Goal itself is no longer achievable?" This probes your knowledge of a rare but important scenario: the Product Owner has the authority to cancel a Sprint if the Sprint Goal becomes obsolete.

ONE CONCRETE EXAMPLE: "In a recent sprint, our goal was to launch a new checkout page. A task to integrate a third-party payment provider, estimated at 3 days, revealed a major API incompatibility after 2 days of work. We projected it would now take 8-10 days. At the next Daily Scrum, I raised this. As a team, we agreed the Sprint Goal was at risk. We immediately pulled in our Product Owner, explained the situation, and proposed descope options. We suggested moving a lower-priority item, 'Add guest checkout analytics,' to the next sprint. The PO agreed. This freed up enough capacity to absorb the integration work, and we successfully met our Sprint Goal of launching the new checkout page."