Flow of Dependency Management in Jira Align

[#1]

The following image depicts the dependency workflow in Jira Align. In Jira Align a dependency is a contract between two teams wherein the requesting team creates the contract and the responding team accepts the contract or proposes changes in the contract which then go back again to the requesting team and the negotiations starts again.

Lets look at the dependency flow in more detail while exploring each step and also see some screenshots

Step -1

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

Now, the dependency has been created. It will now start showing up in the “ToDo” list of the dependency grid view of the stakeholders of the Cowboys team.

Steps-2

As you can see in the below image, once we access the Dependency grid view (under Program on the left blue navigation bar) then in the “To Do” section we can see the dependency. This is working like this because I have added myself as a member of the Cowboys team, hence this view will be visible to the members of the “Depends on” team which is Cowboys in this case.

Now, lets look at the two most probable options for Cowboy stakeholders - Either you Agree to “Needed by” sprint and commit to the dependency or your 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 then this means you can commit to and deliver this dependency by any sprint upto and including S25

As you can see in the above image the dependency is now committed and the “committed by” sprint is S25, this could have been any sprint upto S25 i.e. also S23, S24 etc as all these sprints are before the “needed by” sprint which is S25

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

Till now, we know that if we pick a sprint upto the “Needed by” sprint then we are in the “happy flow” of things but what if your team doesn’t have the capacity to work on the dependency by S25 and instead you want Commit to the dependency at a later sprint.

In this image, you have “Committed” to the dependency at a later sprint i.e. S26 which is after the “Needed By” sprint and thus you get the option of Proposing the new Sprint to the original requesting team (Baltimore) and seek their agreement on the fact that now the dependency can be delivered at a later sprint then what was initially expected (needed by) by the Baltimore team

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

Now, the members of the original requesting team (Baltimore) will get the following view in the Dependency grid view (under Program on the left blue navigation bar)

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

And this is how the dependency object looks

Now, the moment Baltimore team “Accept” the Sprint proposed by the Cowboys team then automatically the “Needed by” sprint is changed to S26 and dependency goes in the state “committed”

So the Baltimore team “Accepted” the new proposed sprint by the Cowboys team, but what if they “Declined” the proposal, then the Dependency stays in the “Not Committed” phase and the Baltimore team have the option of either Blocking the dependency or click on “Request new” to request a new delivery Sprint to the Cowboys team which they will need to accept

Once the click on “Request new” the whole flow of proposing a sprint by one team and accepting by the other will start again just like what we saw till now, but they can also block the dependency (as visible in the image below).

This should only be done to highlight a more serious issue and the dependency management flow in Align should never become the substitute of actual communication between the relevant stakeholders of the team. Both the flow in Align and the collaboration between the stakeholders are important & complimentary to one-another.

In this writeup we looked in detail at what to expect at every step of the dependency workflow in Align and how the complete flow works end-to-end.

[Thomas A Mathews]

Thanks for the detailed explanation, Tarun. 

How do we maintain dependencies between 2 Jira Align Programs?

[Tarun Sapra]

Hello @Thomas A Mathews  - For the dependencies between 2 programs, you need to first make sure its enabled in the "Manage dependencies" section under platform settings.

Different dependency views like grid / wheel view can be used for keeping track of dependencies b/w 2 Align program, but ofcourse most important here is the actual collaboration/communication between the program team for the resolution of the dependency. 

Also you can use "email notifications" to schedule alters to relevant stakeholders when dependency is created -https://help.jiraalign.com/hc/en-us/articles/360018773733-10X-Set-Up-Alerts-and-Notifications

[Bodo Stoecker]

Hi @Tarun Sapra

very good explanation. Thanks for that.

With regards to the dependency flow and the needed handshake between requesting and requested party, the chat functionality within a dependency comes quite handy in order to quickly discuss and negotiate things.

I have seen that within a dependency chat, one can tag other users with @<username> in order to notify them, just like in discussions within Epics, Capabilities, Initiatives, etc., where they will get a corresponding email notification. However, for dependencies no mails seem to be generated when tagging other users. Can you confirm this?

Thanks
Bodo

[Tarun Sapra]

Hello @Bodo Stoecker 

As per the docs, below is the list of work items that support notifications via the discussion link - 

Though you can tag the relevant person in the chat section of the dependency and they are notified when they login to Align. So when the user logs into Align they should see the red notification at the top right in the notification icon but won't receive an email directly when they are tagged in the dependency chat section.

I hope this answers your question.

Regards,

Tarun

[elaine_paton]

Great article! 

For the field "What is this dependency for?", I understand this is the feature which needs the dependency so that it can be delivered successfully (and not the feature which delivers the dependency). 

For example  Team B have a dependency on Team A to deliver feature A, so that Team B can deliver their feature B.   Feature B is the one referenced in the dependency in Jira Align.  Is this correct?

[Tarun Sapra]

Hello @elaine_paton 

The use-case which you have defined, in this you can have feature B connected to the dependency object. And this use-case is more of a "work sequencing" issue instead of regular dependency management. 

The intent behind dependency management in Align is that teams collaborate together to deliver solutions i.e. basically a contract b/w the two teams. The idea is to trigger the right conversations by making things visible across teams and across programs. 

So yes, "work sequencing" is also something which you can leverage dependency management for, but you can also use for example, roadmap view with the right start and end dates to get a view as to when a feature ends and the the other one starts.

[Anne Leduc]

Are these dependencies between teams from different programs? Seems if teams were in the same program, the use of predecessor/successor would be better? Please advise.

[Tarun Sapra]

Hello @Anne Leduc 

Thats a good question, yes we can use the "predecessor/successor" links when the number of teams are less, but as an RTE if you have 10 teams in your train and even if the dependencies are within the same ART/Program then Align supports some excellent views (grid, wheel view) apart from the information on the program board.

Thus using the dependencies map and program board with dependencies will give you a much more holistic view of all intra and inter program dependencies and thus ability to make more informed decisions.

Also, if the number of dependencies are high with in the same Program then that might be the signal towards too many hands-off taking place for the work to be delivered or teams formed as components teams instead of the possibility of exploring the formation of feature teams. 

[Anne Leduc]

Thank you @Tarun Sapra that is valuable details. Appreciate the follow up. 

[Triveni A M]

@Tarun Sapra How can a story be linked to the DEPENDENCIES created by other team. Suppose, there is a dependency created and is assigned to Respondent team.

1. Should Respondent team create stories in JA-Dependency under the "Assigned Stories" section like shown in the attachment?

2. Should Respondent team create new feature(Jira Epic) for their team and link the Requested Team EPIC and create stories for newly created feature(Jira Epic)? 

3. Create stories in jira2 and link the Requested Team EPIC?

[Fozey Alqirsh]

If it is an associated capability instead of a associated feature. Would the associated capability belong to the cowboys or Baltimore?

[James C.]

@Tarun Sapra  I am seeing an issue where the depends on team iteration drop down doesn't match the requested by date. For example:

Team A is requesting the Commitment by iteration 3. Team B CAN commit to this ask, but in the committed by drop down they only have iterations 1 & 2 (iterations/dates before iteration 3) as there choice options. Team B has a PI option available with iterations that have corresponding dates, so they should be able to commit, but it's not a value in the drop down. The only thing I can thing of is that Team B is on a different program and the PI with the Iteration 3 has yet to start?

Thoughts?

Another way of asking is that in the case of cross train dependencies, what are the necessary items that team b needs in place to be able to see the corresponding commit by date drop downs? Even if they wanted to propose a future date in my example above, this isn't an option.

[Tarun Sapra]

Hello @James C_ 

Could you maybe validate if the sprints coming from the board of Team B have all the 6 sprints of the PI defined on them and these sprints are coming across in JIra Align and mapped to the anchor sprints.

On the JIra board we can define future sprints, hence the best practices is to create all the 6 future sprints for each team at the start of the PI on the jira board so that we don't need to think about the sprint sync again during the PI execution phase.

It shouldn't matter if it's a cross train dependency if both the trains are sharing the same PI cadence.

[James C.]

@Tarun Sapra the sprint 3 is actually a future sprint of team B, and those sprints haven't been created in Jira for Team B (Doesn't exist on the jira team sprint board). The PI for Team B (Different program and PI) has the anchor sprint dates. Team B doesn't have iterations yet created for the future PI either in Jira Align. 

[Tarun Sapra]

Hello @James C_ 

The team sprints on the Jira board can be created for future sprints for the current PI hence around 6. No future sprints need to be created for the future PI but for the ongoing PI, it's a good idea to create the future sprints on the jira team's board and let those sprints sync with the Anchor sprints defined in Align.