Understanding the Dependency Workflow in Jira Align

[#1]

Although this topic has been discussed on multiple platforms, just adding to the collection of dependency management. The image shows the dependency workflow in Jira Align. A dependency is a contract between two teams: the requesting team creates it, and the responding team either accepts it or proposes changes, which return to the requesting team to restart negotiations.

Let's examine the dependency flow in detail, exploring each step and viewing some screenshots.

Step -1

You create a dependency: the requesting Team is Baltimore and the requested (depends on) team is Cowboys. The dependency is needed by Sprint 25 of the PI

The dependency has been created. It will appear in the “ToDo” list of the dependency grid view for the Cowboys team stakeholders.

Steps-2

As shown below, when we access the Dependency grid view (under Program in the left blue navigation bar), the dependency appears in the “To Do” section. This happens because I added myself to the Cowboys team, so this view is visible to members of the “Depends on” team, which is Cowboys in this case.

Now, let's consider the two main options for Cowboy stakeholders - either you agree to the “Needed by” sprint and commit to the dependency, or you propose a new delivery sprint

Step 3 - Option 1 - Agree to “Needed by” sprint and commit to dependency

If you agree with the “Needed By” sprint in the dependency, which is S25, you commit to delivering this dependency by sprint S25 or earlier

As shown in the image, the dependency is now committed and the “committed by” sprint is S25, which could be any sprint up to S25, such as S23 or S24, since all precede the “needed by” sprint S25

Step -3 - Option 2 - Pick a sprint after the “Needed By” sprint and send the proposal back to the requesting team

So far, we know that picking a sprint up to the “Needed By” sprint follows the “happy flow.” But what if your team lacks capacity to work on the dependency by S25 and wants to commit to it in a later sprint?

In this image, you have “Committed” to the dependency at a later sprint, S26, which is after the “Needed By” sprint. You can then Propose the new sprint to the original requesting team (Baltimore) and seek their agreement that the dependency will be delivered later than initially expected 

Once you save this change, since you have proposed a new sprint, the dependency will move back to “Not committed” phase.

The members of the original requesting team (Baltimore) will now see the following in the Dependency grid view (under Program on the left blue navigation bar)

Since the Cowboys team committed to a later sprint S26, the Baltimore more can either “Accept” or “Decline” this offer.

This is how the dependency object looks

When the Baltimore team accepts the sprint proposed by the Cowboys team, the “Needed by” sprint automatically changes to S26, and the dependency status updates to “committed”

The Baltimore team accepted the new sprint proposed by the Cowboys team. But if they declined the proposal, the dependency remains in the not committed phase. The Baltimore team can either block the dependency or click request new to ask the Cowboys team for a new delivery sprint, which they must accept

Once you click “Request new,” the sprint proposal and acceptance flow restarts as before, but they can also block the dependency (see image below).

Use this only to highlight serious issues; the dependency management flow in Align should not replace direct communication between the teams' stakeholders. Both Align’s flow and stakeholder collaboration are important and complement each other.