Sprint velocity is highly variable. What technical root causes do you check?

WHAT THIS TESTS: This question tests whether you approach velocity as a noisy planning signal rather than a scorecard. Senior candidates must show they can decompose variance into technical and systemic factors using objective data, without defaulting to people management tropes like motivation or effort. The interviewer wants to hear a structured diagnostic that moves from scope stability to flow metrics to quality drag to estimation hygiene.

A GOOD ANSWER COVERS: Four investigative layers in this order. First, scope stability: check carryover percentages, unplanned work ratios, and mid sprint scope injection by looking at ticket creation dates and status transitions. Second, flow health: analyze cycle time distributions not just averages, WIP limits and aging work in progress, plus queue times in code review and CI pipeline duration, because a clogged pipeline makes finished work invisible to velocity. Third, quality drag and interrupts: measure rework rates, bug escape percentages, production incident frequency, and on call interrupts, since unplanned firefighting displaces committed sprint work. Fourth, estimation noise: examine story point variance within the same ticket types, ticket splitting patterns, and whether the team changed estimation baselines or personnel recently. You should explicitly name the data sources such as Jira state transitions, GitHub pull request metrics, PagerDuty incident logs, and CI build dashboards.

COMMON WRONG ANSWERS: Blaming individual developers for low output or suggesting the team needs to work harder or longer hours. Treating velocity as a key performance indicator that must increase every sprint. Proposing solutions without data, such as adding more engineers before diagnosing queue bottlenecks. Ignoring technical root causes like flaky tests, long running CI, or tech debt that forces context switching. Failing to distinguish between velocity noise caused by estimation inconsistency versus actual throughput changes.

LIKELY FOLLOW-UPS: How would you communicate these findings to a product manager who sees velocity as a commitment metric? What would you do if the data shows estimation is the main issue but the team resists changing pointing scales? How do you balance investigating this against delivery pressure? Would you change sprint length or work in progress limits based on what you find?

ONE CONCRETE EXAMPLE: Suppose velocity jumped from twenty to thirty five points then dropped to fifteen. You pull the sprint burndown and see forty percent carryover in the low sprint but zero in the high one. Cycle time data shows review queue spiked to three days during the low sprint because a critical service had an outage that pulled three developers into incident response. Meanwhile estimation data reveals the high sprint included a five point ticket that was actually a one point config change, indicating point inflation. Your recommendation is not to reprimand the team but to protect twenty percent buffer for unplanned work, cap work in progress at three items per developer, and run a one hour estimation calibration session using historical cycle time as a reality check.

Source: getdx.com