Team Velocity Dropped for 3 Sprints. How Do You Diagnose?

WHAT THIS TESTS: This question tests your ability to practice data-driven leadership and systems thinking. Interviewers want to see if you understand that velocity is a lagging indicator of complex issues, not a performance KPI to be maximized. A great answer demonstrates that you can diagnose problems without creating a culture of blame, and that you know which metrics actually reveal the health of a team's process.

A GOOD ANSWER COVERS: An effective answer has four parts. First, frame the problem correctly by stating that velocity is for planning, not performance, and a drop is a signal to investigate, not a failure. Second, list the quantitative data you'd gather, such as cycle time (especially time-in-stage), commitment-to-completion ratio, percentage of unplanned work, and bug escape rates. Third, describe the qualitative data you'd collect, like reviewing themes from the last three retrospectives and checking team morale. Fourth, explain how you'd present this data neutrally in the retrospective, using it to ask open-ended questions that empower the team to find the root cause themselves.

COMMON WRONG ANSWERS: Red flags include immediately jumping to conclusions or assigning blame (e.g., "It's probably the new hire" or "Sales keeps interrupting us"). Another major error is weaponizing the metric by suggesting a goal like "Let's get velocity back up by 15% next sprint." This only encourages gaming the numbers through story point inflation or quality-cutting. Finally, focusing solely on individual output rather than systemic bottlenecks (like a slow code review process or unclear requirements) shows a lack of senior-level thinking.

LIKELY FOLLOW-UPS: Be ready for: "What if the data is inconclusive?" (Your answer should pivot to facilitating a deeper qualitative discussion, like a '5 Whys' exercise on a specific story that stalled). Also, "What if the team blames an external dependency?" (Your answer should involve gathering specific data on the blocker and facilitating a cross-team conversation). A tough one is, "What if you suspect one person is the cause?" (The correct response is that this is a private management issue for 1:1s, not a public retro topic).

ONE CONCRETE EXAMPLE: "Our velocity dropped from an average of 25 to 18. I pulled data from Jira and saw our 'Time in Code Review' had increased from 1.5 days to 4 days. I brought a chart to the retro showing this trend and asked, 'What's making code reviews take longer lately?' The team identified that two new, complex microservices were causing uncertainty. We decided to dedicate the next sprint's tech-debt time to creating better documentation for them and doing more pair programming, which resolved the bottleneck in two sprints."