How do you respond when a team blames estimates for missed sprints?

WHAT THIS TESTS: This question assesses your leadership and diagnostic skills as an individual contributor. The interviewer wants to see if you can look past the surface-level symptom (inaccurate estimates) to identify the true root causes of delivery failure. It tests your ability to facilitate a blameless, action-oriented discussion, moving the team from complaining about the past to improving the future. It's a test of influence without authority and a mature understanding of agile principles—that estimates are forecasts, not contracts.

A GOOD ANSWER COVERS: A strong answer has four parts. First, validate the team's feelings to build psychological safety, saying something like, "I agree, it's frustrating when work takes longer than we thought." Second, reframe the problem from "our estimates are bad" to "what did we learn?" Ask probing questions like, "What surprised us in the 'Login' story?" or "Were there unexpected dependencies we didn't account for?" Third, categorize the root causes that emerge. Were they technical (unexpected complexity), process-related (scope creep, poor story breakdown), or external (blockers from another team)? Fourth, propose a small, concrete experiment for the next sprint. For example, "For our next complex story, what if we timebox a 4-hour spike to de-risk it before we commit?"

COMMON WRONG ANSWERS: A major red flag is accepting the premise and focusing on how to "get better at estimating." This includes suggesting longer estimation meetings, using different pointing scales (e.g., Fibonacci vs. T-shirts), or blaming the product manager for pressure. These answers miss the point that estimation is inherently imprecise. Another weak answer is to stay silent or defer to the scrum master or manager. A senior engineer is expected to be a leader and actively contribute to improving team processes. Blaming individuals is the worst possible response.

LIKELY FOLLOW-UPS: Expect follow-up questions like: "What if the product manager insists on the original commitment despite the team's concerns?" or "What if one specific engineer is consistently the source of underestimation? How would you handle that?" or "Let's say the root cause is constant scope creep from stakeholders. What's your next step?"

ONE CONCRETE EXAMPLE: "In a retro, I'd say: 'I hear the frustration around our estimates being off. Instead of trying to perfect our estimates, which is really hard, could we look at the two stories we didn't finish? For the payment gateway story, what was the biggest surprise? Was it the API contract, the test environment, or something else?' This shifts the focus from a number to a specific, learnable event. If the surprise was the API, my proposed action would be: 'For our next sprint, let's try to have a joint kickoff with the API team for any story that depends on them.'"