Velocity is fluctuating wildly. How would you coach the team?
Tests whether you treat velocity as a diagnostic, not a target. A strong answer checks story sizing, unplanned work, definition of done, and team stability before changing process. Red flag: demanding higher estimates or comparing teams to normalize velocity.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
A team’s velocity fluctuates significantly between sprints. Which coaching response best applies the principle that velocity is a diagnostic, not a target?
- a.Compare the team’s velocity to a peer squad to identify estimation calibration gaps
- b.Ask the team to increase story points on future stories to buffer uncertainty and level the trend
- c.Switch the estimation scale from story points to hours to eliminate variability caused by relative sizing
- d.Investigate story sizing, unplanned work, and definition of done before running targeted coaching experimentsCorrect
Why? this is the answer
The card emphasizes diagnosing root causes such as oversized stories, untracked interrupts, and shifting definitions of done before adjusting process or running experiments. Padding estimates is a red-flag response because it treats velocity as a target to be gamed rather than a signal of systemic friction.
Just read this? Test yourself on what you have been reading.
Read the original → agilealliance.org
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
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