Dependency Mapping

Purpose

Dependency Mapping makes invisible inter-team and external dependencies visible before they become blockers. By plotting dependencies on a shared board, teams can negotiate delivery order, create buffers, and reduce coordination risk.

At a glance

How to run

1. List work items (10 min) — Each team lists their planned work items for the planning horizon on cards.
2. Identify dependencies (15 min) — For each item, ask: Does this require input from or delivery by another team or external party? Mark each dependency with a connector line or string.
3. Categorize (10 min) — Label each dependency: cross-team, external vendor, infrastructure, regulatory, etc.
4. Assess risk (10 min) — Rate each dependency: High (blocking, no workaround), Medium (workaround exists), Low (nice-to-have timing).
5. Resolve or mitigate (10 min) — For each high-risk dependency, agree on an action: reorder work, create a spike, schedule a sync, or accept the risk.
6. Document (5 min) — Capture all dependencies and actions in a shared tracker.

Materials needed

• Work-item cards (one per planned item)
• String, yarn, or digital connectors for dependencies
• Dependency risk labels (High / Medium / Low)
• Large wall or digital board
• Shared dependency tracker (spreadsheet or Jira links)

Pitfalls & common mistakes

• Only mapping internal dependencies — External dependencies (vendors, compliance, infrastructure) are often the biggest blockers.
• Not assigning owners — Every dependency needs one person responsible for tracking it.
• Mapping once and forgetting — Refresh the dependency map at every planning cycle.
• Too granular — Map dependencies at the feature level, not the task level.

Inclusion & accessibility

• Use colour-coded connectors with text labels (not colour alone) for accessibility.
• Ensure remote participants can add and move connectors on the digital board.
• Provide a pre-populated list of known dependencies to reduce cold-start.

Variations

• Dependency matrix — A table with teams on both axes; cells show dependencies.
• Programme board — Board in the style of large-scale agile frameworks, with swimlanes per team and dependency strings between iterations.
• Network diagram — Visualize dependencies as a directed graph to identify critical paths.

When NOT to use this

• If there is only one team with no external dependencies.
• If the planning horizon is too short (one Sprint) — dependencies are better resolved in Daily Standups.

Source & further reading

• Leffingwell, D. (2020). *SAFe Reference Guide*. Scaled Agile Press.
• Reinertsen, D. (2009). *The Principles of Product Development Flow*. Celeritas.