The Jira Dependencies That Quietly Blow Your Deadline

Most delivery post-mortems focus on speed: we underestimated, we lost people, we should have pushed harder. But a huge share of slipped deadlines have nothing to do with how fast the team worked. They come from order — a piece of work that couldn't start until something else finished, sitting quietly in a "blocks" link nobody was watching. Here are the dependency problems that reliably wreck plans, and how to surface them before they surface you.

1. The blocker scheduled after the thing it blocks

This is the classic. Issue A blocks issue B, but A is planned for Sprint 8 and B is planned for Sprint 7. On the board they look independent — two cards in two sprints. In reality B can't finish until A does, so B is going to slip, and everything depending on B slips with it. The tell is mechanical: a blocker whose due date lands after the start (or due) date of the work it's blocking. It's easy for software to catch and almost impossible to spot by eye across a big board — which is exactly why it survives until it's too late.

2. The circular dependency

A blocks B, B blocks C, and — three links later — C blocks A. Now nothing can start, because everything is waiting on something else in the loop. Circular dependencies are usually accidents of a growing project, and they're invisible unless you walk the whole dependency graph looking for cycles. When one exists, no amount of sequencing saves you until the loop is broken, so finding it is urgent, not cosmetic.

3. The child that outlives its parent

An epic or parent is due before a child issue under it — a quiet inconsistency that means the parent can't really be "done" when it claims to be. It rarely feels dramatic, but it's a sign the plan's hierarchy and its dates disagree, and those disagreements compound.

The number that actually sets your floor: the critical chain

Once you're taking order seriously, one concept matters more than any other. The earliest a project can possibly finish isn't set by how many people you have — it's set by the longest chain of work that must happen strictly in sequence. That's the critical chain: follow the blocker links end to end, add up the durations, and you have a hard floor. Even with infinite capacity, you cannot beat it. Any forecast that comes in earlier than the critical chain is fiction. So the honest question isn't just "do we have the capacity?" — it's "does our capacity date even clear the floor the dependencies set?"

Why this compounds across projects

Dependencies don't stop at a project boundary. When one project slips past the date another project was counting on — and there's a "blocks" link between them — the delay cascades: the downstream project inherits the slip whether or not its own plan was sound. A team can be executing perfectly and still miss, because an upstream team they depend on ran late. Surfacing those cross-project links is the only way to see a miss coming that isn't your fault.

What to do about it

You don't manage dependencies by staring harder at the board. You manage them by having the ordering checked continuously: flag any blocker scheduled after the work it blocks, hunt the graph for cycles, and always measure your forecast against the critical-chain floor — not just against capacity.

Project Commander runs all of these checks on your live Jira project. It flags cross-sprint blockers and blocker-after-blocked conflicts, finds circular dependencies by walking the whole graph, computes the critical-chain floor so your forecast can never read earlier than the dependencies allow, and surfaces cross-project cascades when one project's slip threatens another.