Investigating Variable Sprint Velocity: Technical Root Causes

What's really being asked

This question assesses your diagnostic skills as a senior engineer. It's not about Scrum theory; it's about your ability to connect a symptom (variable velocity) to potential root causes within the engineering system. The interviewer wants to see if you think in terms of systems, data, and testable hypotheses, rather than blaming people or process. They are evaluating your ability to look at metrics like PR cycle time, build failures, or deployment frequency as indicators of underlying friction that manifests as unpredictable output.

The full answer

A structured, data-driven approach. First, acknowledge that velocity is an output metric and variability is a symptom. Second, propose 3-4 specific, technical hypotheses. Examples include: increased CI/CD failures, high merge conflict rates due to monolithic architecture, developer environment instability, or a new source of flaky tests. Third, for each hypothesis, state what data you would pull. For CI/CD failures, you'd look at build success rates over time. For merge conflicts, you'd analyze PR cycle time and time spent resolving conflicts. For environment issues, you might survey the team or look at time-to-first-commit on new tickets. Fourth, explain how you'd differentiate between causes and what your first step would be (e.g., "If CI failures spiked 30% in the last month, I'd start there").

The mistakes people make

A major red flag is immediately jumping to non-technical causes like "the team is bad at estimating" or "product keeps changing requirements." While these can be factors, the question specifically asks for technical root causes. Another weak answer is offering vague hypotheses without mentioning specific data to validate them (e.g., "Maybe our builds are slow"). A senior answer quantifies this ("I'd check if P95 build time increased by more than 20%"). Blaming individuals is the biggest red flag and shows a lack of systems thinking.

What usually comes next

"Let's say you discovered that PR review time has increased by 40%. What would you investigate next?" (Tests your ability to drill down further). "How would you differentiate between a technical problem and a process problem?" (Tests your understanding of socio-technical systems). "What if you have no data available? What's your first step?" (Tests your ability to establish baseline metrics).

A concrete example

"In the last three sprints, our velocity was 30, then 15, then 25 points. I'd hypothesize a technical bottleneck is causing this swing. My first check would be our CI/CD dashboard. I'd pull the build failure rate for our main branch over the last 6 sprints. If I see the failure rate jumped from a stable 5% to over 20% three sprints ago, that's a strong signal. This directly impacts developers' ability to merge completed work, causing story points to spill over into the next sprint and creating unpredictability."