Skip to content
tezvyn:

How would you coach a team with fluctuating velocity?

Source: agilealliance.orgMediumHow cards are made

This tests your ability to use metrics for coaching, not just reporting. A good answer reframes the goal to predictability, investigates both qualitative and quantitative data, and proposes experiments. A red flag is treating velocity as a performance metric.

What's really being asked

Your understanding that velocity is a diagnostic tool for the team, not a performance report for management. It assesses your ability to move from data to diagnosis to coaching, resisting pressure to simply 'fix the number' and instead addressing root causes of unpredictability. The interviewer is looking for a data-informed, systems-thinking approach, not a command-and-control one.

The full answer

Four key steps in order. First, reframe the conversation with management to focus on predictability for forecasting, not maximizing velocity as a target. Explain that stable velocity, even if lower, is more valuable for planning. Second, perform qualitative analysis by talking to the team: are stories well-defined at sprint start? Are there external blockers or frequent context switching? Is there a high volume of unplanned work or production support? Third, conduct quantitative analysis: look at the types of work (features vs. bugs vs. chores), analyze story point consistency, and examine cycle/lead times, not just velocity. A story scatter plot can reveal outliers. Fourth, propose small, testable experiments like reserving 15-20% capacity for unplanned work or dedicating a sprint to paying down a specific piece of tech debt.

The mistakes people make

Focusing only on the number. Suggesting you'd 'crack down' on the team for missing estimates. Proposing padding estimates to smooth the curve, which destroys the metric's value. Comparing this team's velocity to another team's, which is a fundamental misunderstanding of story points. Treating velocity as a performance KPI to be increased sprint-over-sprint. Blaming the team without investigating the system they work in.

What usually comes next

What if management insists on using velocity for performance reviews? (This tests your ability to educate and manage up). What if the team is resistant to change? (This tests your coaching and influence skills). What if your investigation reveals a single engineer is the bottleneck? (This tests your ability to handle sensitive individual performance issues constructively and privately).

A concrete example

On a past team, velocity swung between 15 and 40 points. An investigation revealed the 40-point sprints had large, multi-sprint stories that were credited all at once, while 15-point sprints were full of un-pointed hotfix work after a release. We implemented two changes: 1) A rule that no story could be larger than 8 points, forcing us to break down work better. 2) We created a 1-point 'hotfix' ticket type to track and make visible the unplanned work. Within three sprints, our velocity stabilized to a predictable 25-30 points, and forecasting became reliable.

Interview question

When coaching a team with highly fluctuating sprint velocity, what is the most effective initial approach?

  • a.Reframe the discussion with management to prioritize predictable delivery over maximizing velocity.Correct
  • b.Compare the team's velocity to other high-performing teams to set a target.
  • c.Implement a policy to pad estimates by 20% to create a smoother velocity trend.
  • d.Mandate stricter adherence to story point estimation rules to reduce variance.
Why?

The card emphasizes that the first step is to reframe the goal from maximizing velocity to achieving predictable delivery for forecasting. Other options represent common pitfalls like treating velocity as a performance metric or manipulating estimates, which destroy its diagnostic value.

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.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.

See open roles