Dependencies Management

While the techniques included in this article are specifically for Azure DevOps, other Agile/Scrum tools provide similar capabilities.  Jira, from Atlassian, has a number of plug ins which can help with dependency mapping.

For Process Best Practices see Managing Dependencies on a Scaled Agile team

Azure DevOps Implementation

Azure DevOps allows users to link two work items together.  For dependency management it is best to use the Predecessor and/or Successor links.

How to create a Predecessor Link between two user stories

	The user story has been assigned to a specific team The user story has been assigned to a specific iteration The user story does not have any Related Links.
	Note that both user stories have different Area Paths (Teams) and Iterations. Click on the + Add Link down arrow (#3), which will show the following menu.  Select Existing.
	Select the Link type Down Arrow shows link list Select Predecessor Either use the Work Item ID or search based on the title of the work item Select the appropriate work item from the list Click OK The end result will show the new Predecessor link (see #3 above)

 Useful Queries to Review Dependencies

 User Stories Dependent on another Team's User Stories

Type of Query - Work items and direct links Removed User Stories are ignored The team name (Area Path)  and all items under the area path The team name (Area Path) is not included in the child portion of the query, which is why the Not Under option is used Filter on work items that match the links Return selected link types Set the link type to Successor At the bottom is the end result of the query.

Visualizing Dependencies

At the time when this article was published (01.27.2020), there are two Marketplace tools which can be used to visualize dependencies.

Work Item Visualization - This tool will show any link type between work items, including predecessor and successor links.

Dependency Tracker (Microsoft Extension) - This tool can provide a more comprehensive view of dependencies between teams and projects. Consuming Dependencies shows work items that are producers (predecessors) and work items that are consumers (successors) and provide a visual chart concerning the state of all of the dependencies.  Grey - Not started Blue - Active Green - Closed Dependency Tracker menu item Blue block is a work item that is currently in an active state Green block is a work item that is current closed This column shows the team that will consume the work item This column shows the team that will produce the work item

Introduction

The last two years I have been working with a large team using SAFe to implement a very large system for one of our clients.  There were nine development teams, plus support teams.  I was one of the Scrum Masters on one of the teams.  One of the most important things I learned from my time working on this program is how to manage dependencies between teams that are working on a release train.  This becomes even more important when there are multiple release trains working on a portfolio of programs which have to be integrated into a single system.

In many ways this problem is the same kind of problem that we faced when doing waterfall projects and documenting the dependencies in a GANTT chart.

SAFe Program board showing features and dependencies

During the PI Planning effort in SAFe there is a deliberate effort to capture dependencies between teams and the features they are planning on implementing in the next program iteration.  This process does a good job, during PI Planning of capturing dependencies, especially at the Feature to Feature level.

Best Practices

Pre-PI Planning

 Product Owners, Business Analysts and Architects need to develop a common understanding about what will be in the next PI before PI planning starts.   The effort needs to be focused on upcoming Epics and Features.  The Epics and Features should be detailed enough for the development teams to break into User Stories during the Innovation and Planning (IP) Sprint.

IP Sprint Planning

During the IP Sprint the development teams need to come to a common understanding about the Epics and Features for the next PI so they can break the Features they will be working on into User Stories.  The User Stories need to be detailed enough to a Title and the "As a user..." statement with a sentence or two of description.  Acceptance Criteria can wait for a later point in time.

The final set of tasks prior to PI Planning should be to enter the user stories into the system of record (Azure DevOps, Jira, etc.) and print out the user stories so they can be used during the PI Planning Meetings.  Make sure to include the Title and ID on the printed user story and limit the size to a standard index card.

PI Planning

In addition to updating the Program Board, teams should identify specific user stories that have dependencies and talk with the team they are dependent on.  Each team should exchange a sticky that identifies each teams user story and ID.

For Example:

Sprint 1

Each team is responsible for making sure implement the dependencies that were documented during the PI Planning Meetings in the system of record.  See Implementing Dependency Management using Azure DevOps.

At the end of the first week of Sprint 1, the Release Train Engineer or Program Manager should review the results of the SAFe Program board vs. the information in the system of record.  If there are discrepancies they should be resolved immediately.

Thank you and acknowledgement to

This blog came about after listen to a very old webinar called Collaboration at Scale: Managing Dependencies Across Large Teams which focused mainly on the reasons for dependencies.

Scaled Agile Inc. and their SAFe methodology which provide necessary tools and processes that many development organizations need in order to implement large programs using dozens to hundreds of teams.