Velocity is fluctuating wildly. How would you coach the team?

WHAT THIS TESTS: This question tests whether you see velocity as a team health diagnostic rather than a management target. Senior candidates must show they can separate signal from noise, protect the team from metric gaming, and use data to guide experiments instead of blame.

A GOOD ANSWER COVERS: First, validate the data itself by asking if story points are being re-estimated mid sprint, if the definition of done has changed, or if the team composition is stable. Second, investigate sources of variability such as unplanned work, production incidents, context switching from other projects, or stories that are too large and carry over. Third, look at sprint planning discipline including whether the team is committing beyond its historical throughput or if scope is being added after planning. Fourth, propose coaching experiments rather than mandates, such as capping story size at eight points, carving out fixed capacity for interrupts, or running a spike to reduce technical uncertainty before committing. Fifth, reframe the conversation with management by showing a control chart or throughput trend instead of a single velocity number, and explain that predictability comes from stable flow, not higher estimates.

COMMON WRONG ANSWERS: Promising to increase velocity or make it flat through pressure. Suggesting that the team should estimate higher to buffer for uncertainty. Comparing this team's velocity to another squad. Ignoring the data entirely and saying velocity does not matter. Proposing to change the estimation scale or switch to hours without first diagnosing why the variation exists.

LIKELY FOLLOW-UPS: How would you explain a velocity drop after adding a senior hire. What would you do if management sets a fixed scope and date target based on the average velocity. How do you handle a product owner who adds stories mid sprint and then questions why velocity is inconsistent.

ONE CONCRETE EXAMPLE: Imagine a team whose velocity swings between twenty and forty five points. You review the backlog and find that twenty point stories are actually epics that carry over. You also discover that on call support consumes roughly thirty percent of capacity but is not tracked in the sprint backlog. You coach the team to split stories so none exceed eight points, and you negotiate with leadership to staff a rotating interrupt buffer of two developers per sprint. After three sprints the carry over drops by half and the range tightens to thirty to thirty five points. Management sees the narrower band and begins to trust the forecast.