Cross-board dependencies

Cross-board dependencies is the share of active work items on a board that are blocked by, or waiting on, work owned on a different board. If a board has 40 active items and 12 of them cannot move until another team ships something, the cross-board dependency rate is 30 per cent. The metric answers a simple question that burndown charts hide: how much of this team delivery actually sits in someone else hands.

Dependencies are normal. A platform team builds the API, a product team consumes it. The risk is not that dependencies exist, it is that they go uncounted. When a dependency lives only as a comment on a ticket, nobody owns the link and nobody is warned when the upstream item slips. Measuring cross-board dependencies turns those informal handoffs into a number you can track, so a board that quietly accumulates external blockers shows up before the sprint review, not during it.

The metric is most useful when read alongside delivery flow. A high cross-board dependency rate paired with a rising cycle time tells you that external waiting, not internal effort, is what is slowing the team down. A low rate on a board that still misses dates points the investigation back inside the team instead.

The headline rate divides items that depend on another board by total active items. To make it actionable, capture each dependency as an explicit link with a direction and an owner, not as free text. The inputs below are what you need to record before the rate means anything.

1. 1

   Total active items

   Every in-progress and ready-to-start item on the board. Done and backlog items sit outside the denominator because they are not currently at risk of being blocked.

2. 2

   Blocking dependency count

   The number of active items that have at least one open link to an item on a different board. An item with three external blockers still counts once towards the rate, though you track all three for resolution.

3. 3

   Dependency direction

   Whether this board is waiting on another (inbound) or another board is waiting on it (outbound). Inbound links threaten this board dates. Outbound links mean this board is on someone else critical path.

4. 4

   Dependency age

   How long each link has been open. A dependency that has sat unresolved for three weeks is a different risk from one raised yesterday, even though both count the same in the headline rate.

Cross-board dependencies is a headline number that hides several different problems. A metric tree decomposes it into the drivers underneath, so instead of seeing one rate climb you see whether the cause is more inbound blockers, ageing links, or a single upstream board that keeps slipping. Each branch points to a specific team and a specific behaviour.

The gap between a dashboard and a decision is ownership. A dependency rate on a screen tells nobody what to do. KPI Tree gives every node in the tree a RACI owner, so the accountable person for the upstream board is named on the branch that drives the blockers. When the blocking-item count rises, the push goes to that owner, not to the team being blocked. The verified impact loop then checks whether resolving the flagged links actually brought the rate down, so you learn which interventions clear dependencies and which only move them around.

There is no universal target, because a tightly coupled platform team will always carry more dependencies than a self-contained feature team. The useful read is the trend and the band a board sits in. The ranges below are practical guides drawn from delivery teams running linked boards, not formal standards.

Improving the metric does not mean driving it to zero. It means reducing surprise dependencies, resolving the ones that exist faster, and giving every link a clear owner. The cards below cover the moves that move the number for the right reasons.

1. 1

   Counting soft references as dependencies

   Linking every related item inflates the rate until the number is noise. Reserve the count for items that genuinely cannot progress without the upstream work.

2. 2

   Tracking the rate without the ageing

   A flat dependency rate can hide links that are getting steadily older. Always read the headline number next to how long the open links have been waiting.

3. 3

   Owning the link on the blocked side

   The team being blocked cannot resolve a dependency it does not control. The owner has to sit on the board that delivers the blocker, or nothing moves.

4. 4

   Treating all dependencies as bad

   Some coupling is the correct design. Driving the rate to zero by duplicating work across boards usually costs more than the dependency it removes.