Team struggles with Sprint spillover. How do you investigate?

WHAT THIS TESTS: This question isn't about Scrum trivia. It tests your ability to think like a systems diagnostician. The interviewer is looking for a candidate who can move beyond blame, facilitate a team-led investigation, and use data to drive improvement. They want to see if you understand that spillover is a symptom, not the root disease, and that the causes can be technical, process-related, or cultural.

A GOOD ANSWER COVERS: A strong answer is structured as a diagnostic process. First, state that you would start by gathering data with the team, not by imposing a solution. Use the retrospective as the primary forum. Second, categorize potential root causes to show breadth of experience. Good categories are Upstream (poor refinement, vague Definition of Done, stories too large), In-Sprint (unplanned work, under-estimated complexity, blocking dependencies, tech debt), and Downstream (slow CI, manual QA bottlenecks, complex release process). Third, propose a method for the team to investigate, like a '5 Whys' or fishbone diagram exercise on a specific story that spilled over. Finally, suggest small, reversible experiments to test a hypothesis, like 'Let's try committing to 15% fewer story points next sprint and see if we finish everything.'

COMMON WRONG ANSWERS: Weak answers jump to a single solution or assign blame. Red flags include: 'The team just needs to estimate better' (ignores complexity and discovery), 'Engineers are gold-plating things' (blames individuals, not the system), 'We need to add more buffer' (a patch, not a fix), or 'Scrum isn't working for us' (avoids responsibility for making the process work). The worst answers suggest escalating to management as a first step.

LIKELY FOLLOW-UPS: Be ready for specifics. 'What if the data shows one specific engineer is the bottleneck?' (Probe for causes: Are they the only one with certain knowledge? Are they getting all the interrupts? Is it a skill gap that needs training?). 'What if the Product Owner keeps adding work mid-sprint?' (Discuss protecting the sprint, creating a fast-track process for urgent items, and making the cost of interrupts visible).

ONE CONCRETE EXAMPLE: 'In a past role, our team had 20-30% spillover each sprint. During a retro, we analyzed a ticket that missed the deadline. We discovered it spent 3 days waiting for a code review. The root cause wasn't slow coding; it was an unstated team norm that only two specific seniors could approve PRs in a critical service. Our experiment was to formalize a PR checklist and empower any two mid-level+ engineers to approve. We measured the 'time-to-review' metric, and it dropped by 70%. Our spillover was nearly zero the next sprint.'