How do you handle wildly fluctuating team velocity?

WHAT THIS TESTS: This question tests your understanding that velocity is a tool for team forecasting, not a performance metric for management. It probes your ability to diagnose systemic issues, coach a team towards improvement without being prescriptive, and manage stakeholder (management) expectations. The interviewer wants to see if you can move beyond reporting a number to facilitating a root cause analysis.

A GOOD ANSWER COVERS: A strong answer has four parts. First, reframe the conversation with management. Explain that the goal is predictable delivery, not necessarily higher velocity, as predictability enables reliable business planning. Second, facilitate a team-led investigation, likely in a retrospective, to explore the 'why' behind the fluctuations. Third, present a list of potential root causes to investigate, such as inconsistent story point estimation, unaccounted-for unplanned work, hidden dependencies, or volatile team capacity due to holidays or illness. Fourth, propose specific, small experiments to address these causes, like using a rolling 3-sprint average for planning, formalizing spikes for research, or reserving a fixed capacity (e.g., 15%) for interrupts.

COMMON WRONG ANSWERS: A major red flag is treating velocity as a productivity KPI. Answers like "I'd push the team to increase their velocity" or "We need to get our numbers up" are immediate fails. Another common mistake is comparing velocity across different teams, as story points are relative to a specific team's context. Blaming individuals or suggesting overtime to 'catch up' also demonstrates a misunderstanding of agile principles. Finally, simply reporting the numbers without a plan to investigate the underlying system is a weak, junior-level response.

LIKELY FOLLOW-UPS: Expect questions like: "Management insists on seeing velocity increase. How do you handle that?" which tests your ability to push back constructively and educate stakeholders. Another is: "What if the team doesn't know why it's fluctuating?" which tests your deeper diagnostic skills, perhaps suggesting the team track interrupts or analyze cycle time for different story types. They might also ask how you'd adjust for a new hire joining the team.

ONE CONCRETE EXAMPLE: Our team's velocity swung from 30 to 12 to 35. In the retro, we found the 12-point sprint was derailed by two 'simple' 5-point stories that uncovered major tech debt. The 35-point sprint was all small, well-understood tasks. The fluctuation wasn't about effort, but about uncertainty. Our experiment was to introduce a 'Spike' of 1-2 points for any story with significant unknowns. We also started using a rolling 3-sprint average (26 points) for our sprint commitment. This immediately made our planning more realistic and our delivery cadence stabilized around 25-30 points per sprint, making our forecasts trustworthy.