A task takes longer than estimated, jeopardizing the Sprint Goal. Next steps?

WHAT THIS TESTS: This question evaluates your understanding of empiricism and self-management in Scrum. The interviewer cares whether you know that Scrum Teams inspect progress and adapt their plans when reality diverges from forecasts, rather than following a rigid plan or deferring to a manager. It also tests whether you understand the distinct accountabilities of the Developers, Product Owner, and Scrum Master during a Sprint.

A GOOD ANSWER COVERS: First, the team must inspect the deviation transparently, typically during the Daily Scrum or in an immediate focused discussion, because transparency enables inspection and inspection enables adaptation. Second, the Developers own the Sprint Backlog and must adapt the plan themselves, which may involve removing lower priority Product Backlog items, breaking work into smaller pieces, or finding alternative technical approaches. Third, the Developers collaborate with the Product Owner to renegotiate scope if necessary, since the Product Owner is accountable for maximizing value and can help reorder or remove work while preserving the Sprint Goal. Fourth, the Scrum Master serves the team by fostering an environment where self-management can occur but does not take over decision-making or assign tasks. Fifth, if the Sprint Goal itself becomes obsolete, the Product Owner has the authority to cancel the Sprint, though this is an extreme measure and rarely needed.

COMMON WRONG ANSWERS: A major red flag is suggesting the Scrum Master assigns new tasks, adds people to the team, or demands overtime to catch up. Scrum Teams are self-managing and work at a sustainable pace. Another red flag is claiming the Sprint Backlog cannot change until the Sprint Review, which ignores the empirical pillars of inspection and adaptation. Saying the team should simply try harder without changing the plan also signals a lack of understanding of empirical process control.

LIKELY FOLLOW-UPS: The interviewer may ask how you would prevent this situation in the future, which should lead to a discussion about Product Backlog refinement, smaller work items, or improved forecasting techniques. They might ask who is allowed to change the Sprint Backlog during a Sprint, testing whether you know it is the Developers. They could also ask when a Sprint should be cancelled, probing whether you understand that cancellation is only appropriate when the Sprint Goal becomes obsolete, not merely because the work is harder than expected.

ONE CONCRETE EXAMPLE: Imagine a team whose Sprint Goal is to enable user checkout on a mobile app. Halfway through the Sprint, the Developers discover that a third-party payment API integration will take three weeks instead of three days. In the Daily Scrum, the team inspects the blocker and decides to adapt by building a simplified in-house payment stub that still allows end-to-end checkout, meeting the Sprint Goal. The Developers then renegotiate with the Product Owner to move the production API integration to the top of the Product Backlog for the next Sprint. The Product Owner agrees because the current plan still delivers the intended value and feedback loop, and the Scrum Master ensures the team has the environment and support needed to make this adaptation without external interference.