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

A 4-person team's output dropped 40% mid-sprint. Fifteen days remained against roughly twenty-five days of work still on the board; the math did not close on its own. This was Exprovia's own engineering team, not a client's.

The number alone did not say what was wrong, only that something was. A 40% drop across a team of four is not noise: it is either a shared blocker or a shared habit, and the way to tell the two apart is to ask each person separately rather than the group at once.

The cross-team piece was real and I ruled it in rather than out: the backend team had gotten confused about the API rate limits, and the frontend side was making far more calls than it needed to, which slowed every response down. That cost real time, but it did not explain the whole 40%. Sitting with each developer individually surfaced the rest: the less experienced developers on the team were taking complicated paths through problems on the critical parts of the codebase, where a simpler approach existed and they had not seen it yet.

I chose to spend the scarcest resource in the room (my own time, over the weekend in the middle of the sprint) working out simpler approaches to each developer's specific problem in advance, including a change to the architecture plan, rather than waiting for Monday and losing another day to the same pattern. That cost me the weekend. It bought back days the sprint did not have.

I reviewed the sprint board and went to each developer one at a time instead of running it as a group discussion, because the problem was different for each of them and a group conversation would have surfaced the loudest one, not all four. For the cross-team piece, I got the backend team's rate-limit handling corrected so the frontend stopped paying for calls it did not need. For the architecture and approach problems, I worked through simpler paths with each developer over the following days, including the weekend.

Velocity recovered in about four days, and the sprint delivered on its original date. The recovery held because the fix was not "work harder": it was replacing complicated approaches with simpler ones the developers could actually move through at speed.

A velocity drop on a small team is rarely one cause. Here it was two: a cross-team mistake adding real overhead, and less experienced developers taking the hard path through problems that had easy ones. Sitting with each person individually is what surfaced both: a team-wide conversation would have found the first and missed the second.