How do you fix a team that consistently overcommits?

What's really being asked

The interviewer is assessing your ability to move beyond surface-level symptoms (missed stories) to diagnose root causes within the Scrum framework. They want to see if you can distinguish between individual performance issues and systemic process failures. This is a test of your senior-level diagnostic skills and your ability to facilitate team improvement through influence, not authority. They're looking for data-driven, collaborative solutions, not top-down mandates.

The full answer

A strong answer outlines a two-part approach: investigation and action. First, for investigation, you would look into common causes like external pressure to please stakeholders, a misunderstanding of team capacity (e.g., not accounting for meetings or holidays), a lack of psychological safety to say "no," and poorly refined backlog items that lead to underestimation. Second, for action in the next retrospective, you would propose specific changes. These include using historical velocity as a realistic planning guide (not a goal to be inflated), tracking and recalculating actual team capacity each sprint, timeboxing planning sessions to focus on a clear sprint goal, and implementing more rigorous, collaborative backlog refinement sessions.

The mistakes people make

A major red flag is blaming the team's performance or suggesting punitive measures, like saying "the engineers need to work harder." Another weak answer is "we need to be better at estimating," because it doesn't address why estimates are wrong. Suggesting you would unilaterally change the process or dictate the sprint commitment is also a red flag, as it violates the Scrum principle of a self-organizing team. Finally, ignoring the "people" aspect—like psychological safety or stakeholder pressure—and focusing only on story points is a junior-level mistake.

What usually comes next

Expect questions that dig into the "how." For example: "What if the Product Owner is the one pushing for overcommitment? How do you handle that conversation?" or "The team says historical velocity is too low and they feel they should be doing more. What do you do?" Another likely follow-up is, "How would you measure if your proposed changes are actually working over the next few sprints?"

A concrete example

"In our last sprint, we committed to 40 points based on a guess, but our historical average is 30. We only delivered 25. For the next sprint, I'd propose we start with our 30-point average as the baseline. Then, I'd ask everyone to subtract any planned time off or all-day meetings. If that reduces our capacity by 10%, our new target should be around 27 points. We commit to that, and if we finish early, we can pull in the next item. This creates a win and rebuilds confidence."