Cross-team dependencies in release planning are the most reliably underpriced risk in a delivery plan. Every team forecasts its own work honestly, every forecast is defensible on its own, and the release still slips — because the thing that moved the date belonged to the gap between two teams, and nobody’s burndown was watching that gap. The forum version of this conversation always arrives at the same complaint: we identified the dependency at PI planning, wrote it on a sticky, and then never looked at it again.

Why the dependency is invisible until it is late

A dependency has an unusual property: it is not on anyone’s critical path until it is on everyone’s. The providing team sees a normal backlog item with a normal priority. The consuming team sees a blocker that will not become urgent until the sprint it blocks. Both views are locally correct, and neither view contains the release date.

That is why the escalation always feels sudden. The signal was available for weeks — the providing team quietly re-prioritised, or their own sprint slipped two days — but the information never reached the plan that cared. Conway’s law explains why these gaps exist in the first place; we covered that in Conway’s Law: your org chart drew the dependency map. This is about what to do once they do.

Four things a dependency needs before it is manageable

A sticky note with two team names on it is a record, not a control. Make each dependency carry four fields.

1. A named owner on the providing side. Not a team — a person. “Platform owes us the API” has no one to ask on a Tuesday.
2. A need-by date, not a want-by date. The date the consuming team is blocked if it does not arrive. That date is derivable from the consuming team’s plan, and it is the only date that matters.
3. A price in days. If this lands a week late, what does the release date do? Most dependency registers stop at “high / medium / low”, which is a severity, not a cost. A risk that is never converted into days never competes with anything for attention.
4. A refresh cadence. Status as of PI planning is worthless by week three. Someone re-checks it, on a schedule, and the check is cheap enough to actually happen.

The Scrum of Scrums is the usual venue for the fourth item and usually the weakest link in the chain — the meeting exists but reports status instead of re-pricing risk. Our take on fixing that meeting: make the cross-team dependency meeting count.

Direction matters more than count

Teams often report a dependency count as a health metric. It is close to useless on its own. Twenty dependencies your team provides to others is a workload problem. Three dependencies your team consumes from a team with a different roadmap and a different manager is a schedule problem — and the second one will move your date first.

The other distinction worth tracking is whether the dependency is inside or outside the planning boundary. Inbound work from a team in the same release train can be re-sequenced in a planning session. Inbound work from a vendor, a shared platform group, or another agency cannot — and needs a buffer, a fallback, or a scope decision made in advance rather than discovered in week eight.

Making it visible in Jira

Jira issue links record that a dependency exists. They do not show you the shape of the network, and they do not tell you which link is currently threatening a date. Dependency Manager for Jira turns those links into a view you can read in one pass: what blocks what across projects and teams, where the chains run deep, and which blockers are not moving. That is the difference between knowing a dependency is logged and knowing it is a problem this week.

The second half is connecting that to the date. Advanced Release Planning, Roadmaps & Management for Jira holds the release view — scope, progress, and projected date — so a blocked chain shows up against the release it endangers rather than sitting in a register nobody reads. A dependency that has been priced in days against a named release is a dependency that gets managed.

Where this fits

Dependencies are one of the four things that move a release date, alongside scope, capacity, and estimation error. For the full picture, start with the pillar: Release Planning: A Complete Guide for Agile Teams in Jira. If your team is still deciding which planning layer owns this problem, release planning vs sprint planning draws the line — and managing release scope creep covers the failure mode that most often hides behind a late dependency.

For the mechanics of setting this up across teams, from shared Fix Versions to Plans in Advanced Roadmaps, see our step-by-step guide to planning releases across multiple teams in Jira.

If that date came out of a Program Increment planning session, the timing is worth sitting with: the room voted honestly on planning day, and the dependency network moved afterwards. That is exactly what a PI planning confidence vote cannot tell you six weeks later — which is why the vote is worth carrying forward rather than filing.

A dependency nobody owns is not a risk. It is a date that has already moved and has not told you yet.