How would you coach a team with fluctuating velocity?

WHAT THIS TESTS: Your understanding that velocity is a diagnostic tool for the team, not a performance report for management. It assesses your ability to move from data to diagnosis to coaching, resisting pressure to simply 'fix the number' and instead addressing root causes of unpredictability. The interviewer is looking for a data-informed, systems-thinking approach, not a command-and-control one.

A GOOD ANSWER COVERS: Four key steps in order. First, reframe the conversation with management to focus on predictability for forecasting, not maximizing velocity as a target. Explain that stable velocity, even if lower, is more valuable for planning. Second, perform qualitative analysis by talking to the team: are stories well-defined at sprint start? Are there external blockers or frequent context switching? Is there a high volume of unplanned work or production support? Third, conduct quantitative analysis: look at the types of work (features vs. bugs vs. chores), analyze story point consistency, and examine cycle/lead times, not just velocity. A story scatter plot can reveal outliers. Fourth, propose small, testable experiments like reserving 15-20% capacity for unplanned work or dedicating a sprint to paying down a specific piece of tech debt.

COMMON WRONG ANSWERS: Focusing only on the number. Suggesting you'd 'crack down' on the team for missing estimates. Proposing padding estimates to smooth the curve, which destroys the metric's value. Comparing this team's velocity to another team's, which is a fundamental misunderstanding of story points. Treating velocity as a performance KPI to be increased sprint-over-sprint. Blaming the team without investigating the system they work in.

LIKELY FOLLOW-UPS: What if management insists on using velocity for performance reviews? (This tests your ability to educate and manage up). What if the team is resistant to change? (This tests your coaching and influence skills). What if your investigation reveals a single engineer is the bottleneck? (This tests your ability to handle sensitive individual performance issues constructively and privately).

ONE CONCRETE EXAMPLE: On a past team, velocity swung between 15 and 40 points. An investigation revealed the 40-point sprints had large, multi-sprint stories that were credited all at once, while 15-point sprints were full of un-pointed hotfix work after a release. We implemented two changes: 1) A rule that no story could be larger than 8 points, forcing us to break down work better. 2) We created a 1-point 'hotfix' ticket type to track and make visible the unplanned work. Within three sprints, our velocity stabilized to a predictable 25-30 points, and forecasting became reliable.