Map Dependencies

50 team-map-dependencies

Dependency mapping is a necessary process to ensure code changes necessary for service layers and dependent front-end applications are executed in the proper sequence and with the right data to accomplish the desired functional requirements.

Explore More.

Related Mindset:





User stories, PI Commitments


A dependency map for a PI with identified ownership of identified risks and time based dependency resolution

This process involves the collection of current service capabilities and aligning them against the functional requirements.

As gaps are discovered, each team reports these gaps and a dependency map or graph is created to show the interrelationship between each team. The process includes:

  • Functional requirements: This involves examining the functional requirements and determining what pieces of data and transactions are necessary to fulfill the application needs. In a multiple team program, these requirements will be fulfilled by separate teams and each team must study the requirements and their impact on a given area.
  • Operational requirements: Not only must the team’s fully understand the functional requirements, but there may be operational and technical requirements that have to be factored into the solution as well. This includes deployment dependencies, caching, content delivery services, etc. It’s important to recognize that dependencies are not just code or database updates, but also the configuration and provisioning of infrastructure.
  • Gap analysis: The portfolio of existing services should be examined and used, where possible, to fulfill the data and transaction needs identified above. For cases where the needed data or transaction support is not present, a gap exists. Gaps should be identified within the team(s) responsible for supplying the data or transactional support.
  • Solution services: In order to provide the proper experience for an application, it may be necessary to write additional services to orchestrate the underlying, granular, domain oriented services. A good example of this is a mobile application that wishes to perform a business transaction spanning several domains (teams). Having the mobile application invoke the granular services directly could result in performance issues due to network latency and bandwidth. Instead, a service is needed to orchestrate the domain services into one interface for the client applications. The need for services to fulfill this role should be identified as a gap and added as a development dependency.
  • Level of effort: When the teams have identified gaps, a level of effort is estimated to determine how many iterations (sprints) will be needed to close the gaps.
  • Dependency map: Once the gaps and levels of effort can be identified, a dependency map of the gaps along with the duration needed to close the gap can be assembled.
  • Program board1: Once the dependency map has been created, it can be used as part of the Scaled Agile process to create a program board which will show the dependencies between the teams and modules along with the iterations across which these dependencies span.

Common Pitfalls

Dependency mapping is critical to successful program management.

Success of a program is highly dependent on smooth orchestration of work between teams and in order to accomplish this the dependencies between teams must be fully understood. Some issues that arise in dependency mapping include:

  • Incomplete functional requirements: The resultant dependency map won’t provide an accurate view if the functional requirements are not complete and are not fully understood by all team stakeholders.
  • Team communication: To fully understand dependencies between teams requires them to come together and discuss how gaps will be addressed. Poor inter-team communication or lack of representation from teams will result in an incomplete dependency map.
  • Lack of technical standards: In order for the output from one team to fulfill the needs of dependent teams, a common set of technical standards should be in place. These standards include, but are not limited to, authentication, authorization, data formats, and transport mechanisms needed to let data flow freely between dependent components. If the necessary standards do not exist, the affected teams should note this as a gap and document that they have a dependency on these standards being produced.


Tools for constructing a dependency map can range from physical tools like index cards on a board to software designed specifically for agile dependency management.

  • Physical mapping: Mappings can be as simple as physical index cards with dependencies identified via strings connecting the cards. The problem with this approach is that the physical map is not portable and won’t be accessible for updates to remote participates. A large number of dependencies can make the management of a physical map difficult.
  • Drawing tools: Diagrams can be created via Visio or a cloud-based service like These have the advantage of being accessible to all team members no matter their location. However, these drawing tools are generic and may have limited ability to annotate and describe the dependencies. What’s more, the drawing tool is not integrated with any requirements management or documentation tool.
  • Issue / work management tools: Products like JIRA allow stories to be created with dependency links to be established between them. Several plugins are available for JIRA which can then be used to visualize the dependencies between stories:
  • Requirements management tools: This software was built specifically around requirements management for Agile teams. Among these are: