What do you do when a Sprint Goal is in jeopardy?

What's really being asked

This question tests your understanding of Scrum as an empirical framework for adaptation, not a rigid project plan. The interviewer wants to see if you prioritize the Sprint Goal over the initial Sprint Backlog. They are assessing your ability to act with transparency, facilitate team self-management, and collaborate effectively with the Product Owner when plans change. It's a test of senior-level ownership and problem-solving within the framework, not just following ceremony rules.

The full answer

A strong answer outlines a sequence of four steps. First, immediate transparency: raise the issue at the next Daily Scrum so the entire team is aware of the risk to the Sprint Goal. Second, team-based problem-solving: the Developers (the entire team, not just you) collaborate to inspect the remaining Sprint Backlog and brainstorm options. This could involve swarming on the problem, finding a simpler technical solution, or re-ordering tasks. Third, negotiation with the Product Owner: once the Developers have options, they present the situation and potential solutions to the Product Owner. The goal is to negotiate the scope of the Sprint Backlog to ensure the most valuable work towards the Sprint Goal is completed. Fourth, document the decision: update the Sprint Backlog to reflect the new plan.

The mistakes people make

A frequent red flag is treating the Sprint Backlog as immutable. Candidates might suggest working nights and weekends to "meet the commitment," which indicates a misunderstanding of sustainable pace. Another wrong answer is unilaterally dropping tasks from the sprint without consulting the Product Owner, which undermines the PO's role in maximizing value. A junior response is to simply escalate to the Scrum Master or a manager and wait for instructions, which abdicates the team's responsibility for self-management.

What usually comes next

"What if the Product Owner is unavailable?" (A: The team makes the best decision possible to preserve the Sprint Goal and informs the PO ASAP). "What if the Sprint Goal itself is impossible to achieve?" (A: The team may, in consultation with the Product Owner, decide to cancel the Sprint. This is a rare and serious event, initiated by the PO). "How would you prevent this from happening again?" (A: Discuss the root cause in the Sprint Retrospective, focusing on estimation techniques, risk identification, or how we break down complex work).

A concrete example

Let's say the Sprint Goal is "Allow users to pay with a credit card." A task to integrate with a payment provider, estimated at 3 days, is now looking like 10 days due to unexpected API complexity. At the Daily Scrum, I'd raise this. The team might brainstorm options: can we use a different, simpler provider? Can we implement a 'mock' payment gateway for now to unblock UI work? We present these to the PO. The PO might decide that a mock gateway is unacceptable, but agrees to drop a lower-priority "save card for later" feature to free up capacity to focus on the core payment integration, thus preserving the Sprint Goal.