Cross-Sprint Blockers — the blocker that never showed up on your board
Your sprint ticket is waiting on a ticket that isn't in your sprint. It's not on your board, so nobody's watching it — until the commitment slips. Avium watches it for you.
Sprint 24 is trending to miss — three things need you today.
- Sprint 24 at 72% riskSprint Risk Forecast
Pace is 12 points behind with 4 days left; 2 blockers unresolved.
- Mike is committed to 132% of capacityOver-Allocation
Re-balance 2 tickets before standup or the sprint slips with him.
- APP-43 blocked 9 daysBlocked & Stale
Oldest blocker on the board — make it the first item at standup.
The blocker that isn't on your board
You can see everything on this sprint's board. That's exactly why cross-sprint blockers are so dangerous: the thing blocking you isn't there. A committed ticket depends on work that lives in a future sprint, an earlier sprint that spilled over, or the backlog — and because that blocker never shows up in front of the team, nobody's tracking it.
The ticket sits at 'in progress,' the burndown looks fine, and the dependency quietly ages out of sight. You find out at the sprint review, when the committed work didn't land because the thing it needed was never finished — and was never anyone's job this sprint.
How teams try to catch cross-sprint dependencies today
The methods that don't scale:
- Reading every 'is blocked by' link by hand — Jira stores the link, but nobody opens 40 tickets each morning to walk the dependency chain.
- Trusting that the blocker's team will deliver on time — their sprint is invisible to you, and their priorities aren't yours.
- Catching it in sprint planning — planning checks what's IN the sprint, not what the sprint silently depends on elsewhere.
- Finding out at the review — by then the commitment has already slipped, and 'we were blocked' lands as a surprise.
How Avium Signals computes cross-sprint blockers
Avium already ingests Jira issue links as a typed dependency graph (oriented so the blocker is always the source). For each open ticket in the active sprint, it walks the 'blocked by' edges and applies two tests:
- Is the blocker unfinished? A blocker that's already Done is no risk — it's filtered out.
- Is the blocker outside this sprint? If it lives in another sprint or the backlog, it's a cross-sprint blocker — the silent kind. Same-sprint blockers are the ordinary 'blocked' Signal.
- Backlog blockers rank first — a dependency on un-scheduled work is the most stranded, so it leads the list.
- Severity is never just 'info' — a committed item gated on work the team doesn't own this sprint is at least a warning, and three or more is critical.
Who reads this Signal
See what your sprint is really waiting on
Connect your work management tool (Jira today) and Avium maps your dependency graph automatically. The cross-sprint blocker Signal surfaces on the free tier; Avium Intelligence on Business folds it into a prioritized briefing that names the upstream owner to chase.
Start free — no credit card →