Sprint Velocity Dropped 40% Mid-Sprint: What To Do About It

Output dropped 40% mid-sprint with a hard deadline in front of it. [NEEDS INPUT: what was the team size at the time of this incident?] A team that has grown fast carries coordination costs it never had at its earlier size, and those costs do not announce themselves. [NEEDS INPUT: was this the Exprovia engineering team, or a client team?] The people affected were not only the client waiting on a date, but engineers who by every visible measure were working as hard as they had the sprint before. [NEEDS INPUT: what velocity measure was used, story points, throughput, or completed scope?]

Velocity is a lagging indicator, which is the first thing to hold in mind when it moves. By the time a burndown shows a 40% drop, the cause is already a week or more old and is still running. What made this credible rather than noise was the size of it. Individual off-weeks, sick days and estimation error are normal, and across a team of any size they average out. A 40% drop is structural. [NEEDS INPUT: how many sprint days remained when the drop was identified?]

The reflex explanations were the ones I ruled out first. Underperformance does not scale to that number: for a handful of people to move the whole team down 40%, they would have to have stopped entirely, and that is not what a drop of this shape looks like. Adding capacity was the second reflex and the more expensive error, because if work is blocked then more people produce more blocked work and a wider coordination surface, and the deadline left no room to absorb onboarding. I also declined to treat it as an estimation problem, since re-sizing tickets mid-sprint changes the measurement instead of the throughput.

What I deliberately did not do was ask the whole team in one room. Blockers that implicate another team, and morale problems of any kind, do not get named in a group setting in front of the peers and managers they concern. I ran rapid 1-on-1s instead, working from the assumption that the information already existed inside the team and the format was suppressing it.

I spent the scarcest resource of a deadline week, hours, mine and each engineer's, on diagnosis rather than output. [NEEDS INPUT: how long did the 1-on-1 round take end to end?] That is a bet: if the read was wrong, the remaining slack was gone and I had bought nothing with it. The second tradeoff was structural. Removing cross-team dependencies meant decoupling work that had been designed to be shared, which accepts local duplication and integration cleanup later in exchange for movement now. I took a known cost after the deadline over an unknown one before it. [NEEDS INPUT: which cross-team dependencies were removed?]

The 1-on-1s surfaced the blockers and the morale issues that the group format had been hiding. I redistributed workload and removed cross-team dependencies so the critical path stopped running through other teams' schedules; reassignment costs handoff and ramp time, which is why it is worth doing against a named blocker and not as a general reshuffle. I introduced daily async standups, which produce a written record of what is blocked without taxing every engineer's morning, and clearer acceptance criteria, because work rebuilt after review is velocity that was spent and never counted.

Delivered on deadline. Velocity recovered and held for 6+ months. The second half of that sentence is the part I judge the work by. A recovery that lasts one sprint is a push, and pushes are repaid with interest in the sprint after them. Holding for six months means the changes were absorbed into how the team worked rather than sustained by my attention.

Two things stayed in place. The daily async standup remained the mechanism for surfacing blockers in writing, and acceptance criteria became part of what a ticket must contain before anyone picks it up, rather than something clarified during review. The rule I took out of it is that velocity is an instrument, not a target. When it drops, the number is reporting that something upstream is blocked, and the only useful response is to go and find out what, individually and fast.