Engineering Leadership

How to Spot Blockers Before They Slow Down Your Sprint

Strova Team
Abstract illustration of bars representing blocked work

"Waiting on design" shows up in a standup update on Tuesday. Nobody follows up. By Friday, the ticket's still waiting, the sprint's behind, and the retro question is "why didn't anyone flag this sooner?" The honest answer is usually: someone did. It just didn't look urgent enough to act on.

Blockers rarely announce themselves

A real blocker is almost never phrased like an alarm. It's a half-sentence at the end of an update — "still waiting on the API key," "need someone to review the RFC," "not sure if we're doing X or Y here." Said once, in a room of eight people focused on their own updates, it's easy to nod past.

The problem compounds because the same phrase can mean two very different things: a five-minute question anyone could answer, or a three-day wait on another team. Without something forcing a distinction, both get the same amount of attention — which is to say, none, until it's a sprint risk.

What actually catches these earlier

  • Make "blocked" a field, not a sentence. If updates have to explicitly mark blocked status, it can't slip past as background narration.
  • Route by severity, not just presence. A blocker waiting on an external team is a different problem than one waiting on a five-minute Slack reply. Treating them the same either causes false alarms or trains people to ignore the flag.
  • Look for repetition. The same blocker mentioned two days running is a much stronger signal than a blocker mentioned once. A single day's snapshot won't show you that pattern — you need updates compared across time.
  • Give leads a single place to scan, not twelve separate messages to remember. A board that surfaces "still blocked, day 2" is worth more than a perfect memory of yesterday's standup.

Why this is hard to do by hand

Catching this consistently means someone has to actually read every update, every day, and remember what was said the day before. That's a reasonable ask for a team of four. It stops being reasonable at twelve, and it's essentially impossible across multiple teams.

This is the part of the standup that benefits most from automation — not because a person couldn't do it, but because a person doing it reliably, every day, across a growing team, doesn't scale. Strova's AI reads each update for blocker language, tracks it across days, and flags it on the team's DSM board automatically, so "still waiting on design" on day three gets noticed instead of scrolled past.

#blockers#engineering-management#sprint-planning