Investigating Variable Sprint Velocity

What's really being asked

Your ability to be a systems thinker and a data-driven diagnostician. The interviewer wants to see if you can move beyond surface-level Agile metrics to investigate the underlying technical health of the codebase and development environment. It's a test of root cause analysis, not your knowledge of Scrum definitions. The key is connecting a process symptom (variable velocity) to a technical cause.

The full answer

A structured investigation in three parts. First, acknowledge that variability is the key problem, as it undermines predictability, which is the primary purpose of tracking velocity. Second, propose several specific, technical hypotheses. Examples include increased build/test times, regressions from a new dependency, high code complexity in a specific module slowing down development, or poorly decomposed stories with hidden technical dependencies. Third, for each hypothesis, state exactly what data you would analyze to validate or disprove it. For instance, for slow builds, you'd pull CI/CD pipeline duration metrics; for complexity, you'd look at cycle time per story point or code churn metrics.

The mistakes people make

The biggest red flag is blaming people. Avoid saying "the team is bad at estimating" or "engineers aren't working hard enough." This shows a lack of seniority and an inability to look at the system. Another common mistake is focusing exclusively on process issues like holidays or meetings, ignoring the "technical root causes" part of the prompt. Finally, giving vague answers like "I'd look for bottlenecks" without specifying what they might be or what data you'd use is a sign of a junior mindset. The goal is stable, predictable velocity, not just "making the number go up."

What usually comes next

Be ready for "Okay, you've found the root cause is tech debt in module X. What is your plan to fix it and how do you get buy-in from the Product Manager?" or "What if your data is inconclusive? What are your next steps?" They may also ask, "How do you differentiate between a one-off 'bad sprint' and a trend that needs investigation?"

A concrete example

Let's hypothesize that recent variability is due to flaky end-to-end tests. For the last three sprints, our velocity was 30, then 15, then 25. I'd check our CI dashboard and see that the E2E test suite failure rate on the main branch jumped from 5% to 40% three sprints ago. Rerunning tests often passes, indicating flakiness. This adds 2-4 hours of developer time per PR for investigation and retries, delaying merges and causing story spillover. This data-backed approach isolates the problem beyond just "estimation was off."