Sprint velocity is highly variable. What technical root causes do you check?
Debugging velocity variance with data, not assumptions.
Check scope stability via carryover, flow via cycle time, quality via rework, and estimation via point variance.
Blaming people or treating velocity as a performance target.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
When sprint velocity drops sharply, which diagnostic approach best identifies the technical root cause?
- a.Focus on recalibrating story points since estimation inconsistency explains most velocity noise.
- b.Compare carryover, cycle time distributions, rework rates, and estimation variance to find systemic patterns.Correct
- c.Review individual developer output and discuss increasing commitment in the next retrospective.
- d.Add more engineers to the team to absorb the throughput loss quickly.
Why? this is the answer
The card prescribes a four-layer diagnostic covering scope stability, flow health, quality drag, and estimation hygiene. Option A is tempting because estimation noise is a real factor, but narrowing the investigation to story points alone misses carryover, cycle time, and rework data that reveal true systemic bottlenecks.
Just read this? Test yourself on what you have been reading.
Read the original → getdx.com
- #agile
- #velocity
- #metrics
- #debugging
- #leadership
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles