Cross-Team Dependency Management

Overview

Cross-team dependencies are commitments one team makes to another's delivery schedule. When a team's sprint story depends on an API another team is building, a design another team is producing, or an environment another team controls, the dependency becomes a potential blocker. The teams that manage dependencies well surface them early, negotiate explicitly, and track them until resolved. The teams that manage them poorly discover them mid-sprint.

For managing escalation when dependencies stall, see Escalation Protocols. For communication frameworks that keep dependent teams aligned, see Stakeholder Communication Frameworks.

Why It Matters

Unresolved dependencies are the most common cause of sprint blockers. A developer who cannot proceed because an upstream team has not delivered something has no productive path forward. The day is lost; the sprint is affected.

Dependencies discovered mid-sprint cannot be managed proactively. A dependency identified in sprint planning can be negotiated, scheduled, and unblocked before development starts. A dependency discovered mid-sprint triggers an urgent conversation, disrupts both teams' schedules, and often results in a missed commitment.

Dependency management is a two-way responsibility. The team that needs something and the team that provides it both own the relationship. Waiting for the other team to notice a dependency is not management — it is hoping.

Hidden dependencies make planning assumptions invisible. When a team's sprint plan implicitly assumes that another team will deliver something on time, that assumption is not visible in the plan. If the assumption is wrong, the impact is a surprise. Making dependencies explicit makes the assumption visible.

Early identification creates options. A dependency identified six weeks ahead can be sequenced, staffed, or designed around. A dependency identified six days ahead has one option: escalate and hope.

Standards & Best Practices

Dependency identification cadence

Dependencies should be identified at multiple points:

• During refinement: When a story is written, ask "Does completing this require anything from another team?"
• During sprint planning: Review committed stories for cross-team requirements
• In Program Increment (PI) planning: For teams using SAFe or similar frameworks, dependency identification is a formal part of PI planning
• During risk reviews: At the start of a significant project phase, map all cross-team dependencies explicitly

The RAID log

A RAID log is a structured record of the cross-cutting issues that affect delivery:

• Risks — events that might happen and would negatively affect delivery
• Assumptions — things believed to be true that have not been confirmed
• Issues — problems that are currently affecting delivery
• Dependencies — commitments from other teams required for delivery

Dependencies in the RAID log should include:

• What is needed
• Which team provides it
• When it is needed
• Current status (not started / in progress / delivered / blocked)
• Owner on each side

Blocking vs non-blocking dependencies

Not all dependencies are equal. Classify each one:

Hard blockers that cannot be resolved before sprint planning should prevent the dependent story from entering the sprint.

Interface contracts as dependency resolution

Many cross-team dependencies are interface dependencies — one team builds something that another team consumes. The most effective way to unblock these is to agree on the interface contract early, even before implementation is complete:

• For APIs: agree on the endpoint contract (request/response schema, error codes) in a shared document before either team builds
• For data pipelines: agree on the schema and delivery format
• For shared components: agree on the component API (props, events, slots)

Once the contract is agreed, both teams can work in parallel — one builds to the contract; the other builds a mock of it.

How to Implement

Sprint 0 dependency mapping

At the start of a significant project, run a dependency mapping session:

1. List all deliverables in the roadmap
2. For each deliverable, ask: "What do we need from outside this team to deliver this?"
3. Map each dependency to the providing team
4. For each dependency, identify the latest date it must be available
5. Confirm with the providing team that they can commit to that date
6. Add confirmed dependencies to the RAID log

Any dependency that cannot be confirmed by the providing team is a risk — document it as such.

Weekly dependency review

Once per week (typically in the team's weekly sync), review the RAID log's dependency section:

• Are any dependencies approaching their "needed by" date without being delivered?
• Have any new dependencies emerged since last week?
• Are there any dependencies where the status is unclear — no update from the providing team?

Dependencies with no update after two check-ins should be escalated (see Escalation Protocols).

Communicating cross-team commitments

When another team makes a commitment to deliver something for your team:

1. Confirm the commitment in writing (email, ticket comment, or a shared document)
2. Add it to the RAID log with the agreed date
3. Send a reminder at the halfway point between now and the needed-by date
4. Send a final check-in three business days before the needed-by date

Confirmations that exist only in a meeting conversation are not reliable. Written records prevent "I didn't know you needed it by then" surprises.

Tools & Templates

RAID log template

## RAID Log — [Project / Team name]

### Dependencies

| ID   | What is needed                  | Providing team | Owner (our side) | Owner (their side) | Needed by | Status      |
| ---- | ------------------------------- | -------------- | ---------------- | ------------------ | --------- | ----------- |
| D-01 | Auth API — OAuth token endpoint | Platform team  | [name]           | [name]             | Sprint 4  | In progress |
| D-02 | Design for onboarding flow      | Design team    | [name]           | [name]             | Sprint 3  | Delivered   |
| D-03 | Staging environment credentials | DevOps         | [name]           | [name]             | Sprint 2  | Blocked     |

**Status values:** Not started / In progress / Delivered / Blocked / At risk

Dependency check in sprint planning

During sprint planning, for each committed story:

- [ ] Does this story have any cross-team dependencies?
  If yes: Is the dependency resolved (confirmed delivered or confirmed in-flight with agreed date)?
  If no: Do not commit this story.

Interface contract template

## Interface Contract — [API/Component/Service name]

**Agreed between:** [Team A] and [Team B]
**Date agreed:** [Date]
**Contract owner:** [Name]

### API Endpoint (example)

- **Method:** POST
- **Path:** /api/v1/[resource]
- **Request schema:** [describe or link]
- **Response schema:** [describe or link]
- **Error codes:** [list]

### Assumptions

- [Any assumptions each team is making about the other's behaviour]

### Agreed date for mock / stub availability:\*\* [Date]

### Agreed date for production availability:\*\* [Date]

Common Pitfalls

Verbal dependency agreements. "We agreed in the standup that they'd have it ready by Friday" is not a reliable commitment. Verbal agreements about cross-team deliverables are routinely forgotten, misunderstood, or deprioritised. Confirm in writing.

Waiting for the other team to notice. Teams that assume their dependency is "obvious" to the providing team and therefore requires no explicit communication are setting themselves up for a surprise. Every dependency must be communicated and confirmed explicitly.

Not identifying dependencies until development starts. A developer who reaches a point in implementation where they need something from another team has discovered the dependency too late for it to be managed proactively. Dependency identification belongs in refinement, not in development.

Treating all dependencies as equally urgent. A dependency needed in sprint 8 does not need the same urgency as one needed in sprint 2. Prioritise dependency resolution by "needed by" date. Escalating everything creates noise that reduces the credibility of real urgency signals.

No named owner on the providing side. A dependency tracked as "Platform team will provide X" has no accountability. Dependencies need a named person on the providing side who knows the dependency exists and has committed to a date.

Closing dependencies prematurely. Marking a dependency as "resolved" when the providing team says "we're working on it" rather than "it's done" is common. A dependency is resolved only when the deliverable is available and verified — not when it is promised.