PI Board Dependencies: Track the Full Dependency Chain Across Boards and Tools

Dependencies rarely stop at the edge of a PI Board. A Feature on your board may depend on work in another ART, an item that is still sitting in a backlog, a Solution-level Epic, or something that exists only in Jira or Azure DevOps.

The challenge is not simply knowing that a dependency exists. It is being able to answer, while you are planning:

Kendis brings those answers into one dependency experience on the PI Board.

Dependency Tracking gives you the operational view by team, sprint and location. The Dependency Grid and Team map show the cross-team picture. The Dependency Tree follows the chain across Program Boards, collections, Solution boards and Jira or Azure DevOps.

You can also create, edit and manage dependencies across those locations without leaving the PI Board.

With PI Board Dependencies you can:

Open a Program Board, then select More › Dependency Tracking.

This is the main operational view for dependencies on the PI Board. It opens on the Teams tab and brings together planned, backlog and outside-board dependencies without changing the normal board-loading experience.

Cross-board details are loaded when you open Dependency Tracking, rather than when you open the PI Board itself.

Select + Create dependency in the top-right of Dependency Tracking, next to Dependencies Dashboard.

You can also create a dependency from the Dependency Tree. See Create a dependency.

You can open the tree from four places:

The Dependency Tracking page is designed to answer three things quickly: how many dependencies need attention, which teams are involved, and where the other work lives.

From top to bottom, the page shows:

Hover Outside this Board to see what it covers on your board, for example the other end is on another Program Board or in Azure DevOps.

Total dependencies, Within team, Overdue, Completed, Cross-team and Reverse dependencies.

Tree, Items and Team › Iteration. The last column uses your board's sprint term.

The Teams tab is the main working view during PI planning and execution. It groups dependencies by team in the order of your board's teams, followed by teams from other boards and then teams that only exist in Jira or Azure DevOps.

Each group shows:

Select the header to expand or collapse the group.

An expanded group is split into up to three sections, always in this order:

Each section has its own row with a name, a count and a one-line explanation. Sections start collapsed. Select a section to open it. Kendis remembers which sections you opened.

A group with only one kind of dependency shows no section row.

When you group by receiving team and the receiver is not on this board, the dependency is listed under your board's team at the other end, in that team's Backlog or Outside this Board section. The row's tag still tells you where the receiver lives.

Grouping by creating team works the same way in the other direction.

Each dependency is shown as a card that combines the dependency record with the context of both linked items. The same card format is used across Teams, Backlog and Outside this Board so the information stays consistent as you move between views.

From left to right:

A dependency whose home is another board also shows Home: PI#21, or From PI#21 (closed) when that board is closed.

The body reads top to bottom:

The 1 marks the item that has to be done first: the predecessor or blocker.

For each item you see:

Hover a Team › Iteration chip to see the full team and sprint names. For items in Jira or Azure DevOps, the tooltip shows the full iteration path.

When the item that has to be done first is planned later than the item that waits on it, a red banner says so, for example:

1266 should be completed before 326, but it is planned later.

The tree icon at the start of the card opens the Dependency Tree for that dependency's item.

Placement is a core part of the dependency experience. Every item tells you where the work currently lives, and the same tags and colours are used consistently in the listing, grid and tree.

The tag names the board closest to yours: a board in the same planning window first, then the nearest by dates. The other boards are shown as +N. Hover +N to see them.

Boards you do not have access to are only counted, never named, for example 2 board(s) you cannot see.

For an item that is only in Jira or Azure DevOps, Kendis shows a team when it can:

When no team is found, Kendis shows the project instead, for example Jira › GRN, with a tooltip that explains that no team on this board is mapped to it.

Live data: for an item that is only in Jira or Azure DevOps, the title and status are read live from Jira or Azure DevOps when you open the listing. Items on a Kendis board or in a collection always show their Kendis data.

The Backlog tab isolates dependencies where one end is still in this board's backlog.

This is especially useful during PI planning: it highlights work that other items already depend on, but which has not yet been assigned to a team and sprint.

Rows are grouped by team. An item in the backlog shows the amber Backlog tag, and the team Kendis found for it, for example Backlog › Team Sky.

An item in this board's backlog is this board's own work. It is never counted as Outside this Board.

The Outside this Board tab gives you a dedicated view of dependencies that cross the boundary of the current PI Board. It answers a simple planning question: what are we depending on that is owned or planned somewhere else?

It is organised in sections, each with a coloured bar, a count and a short description:

Sub-groups start collapsed. The checkbox on a card selects all of its rows.

If another Program Board created a dependency towards an item on your board, it also appears here, with that board as its home.

Open Group by to choose:

The pill shows your current choice, for example By Receiver · Team.

Use Teams to show all teams or one team. Choosing one team filters the listing and opens the selected-team view.

Use All, By Epic, By Story or Not visible as Lines. Each option shows its count.

Not visible as Lines lists the dependencies the board cannot draw as a line, for example because neither end is planned on a card of this board.

Search matches keys and titles, including the live titles of items that are only in Jira or Azure DevOps.

Sorting by due date keeps the sections in place and sorts the rows inside each section.

Collapse all closes every group.

Selecting one team turns Dependency Tracking into a focused team view. A summary appears above the listing so the team can see what it depends on, who depends on it, and where attention is needed.

Each card lists the teams of this board first, by count. Below them, one Outside this Board row shows the total and a short summary, for example Other Kendis boards 3, Not in Kendis 1.

Expand the row to see one line per team outside this board. Each line shows the board as a coloured pill, which opens that board, followed by the team.

Select any count to filter the listing to those dependencies.

Outside this Board counts every dependency of the team whose other end is not on this board. Select it to filter the listing.

Dependencies to this board's backlog are counted under With Unplanned Items, never twice.

The matrix lists this board's teams, then a collapsible Outside this Board row with its total.

Teams outside the board have no sprint cells, because their sprints are not this board's sprints.

Kendis remembers whether you expanded the Outside this Board rows on this board.

Open the Dependency Grid tab when you want to move from individual dependency records to the overall pattern between teams.

The grid shows the number of dependencies between each pair of teams, making the strongest cross-team dependency relationships easy to spot.

Two pickers above the grid choose the columns:

Each picker has a search box, Select all and None.

Columns are grouped under This board and Outside this Board. Cells involving a team outside this board use a blue scale. Other cells use a green scale. The darker the cell, the more dependencies.

Select a cell to open its dependencies. They are shown with the same cards as the listing, so you can edit, delete, comment or open the tree from there.

Switch from Grid to Team map to see the same team-to-team dependency picture as a diagram.

The Dependency Tree is the end-to-end view of the dependency network. Starting from one or more items, it follows their dependencies across every open Program Board you can access, collections and Jira or Azure DevOps.

The tree opens over the board. Press Esc or select × to close it.

While a tree is open, the page URL includes the items it was opened on. Copy the URL to share the same tree. Reloading the page reopens it.

Each card shows an item's key, type, title, status, team and sprint.

Each line is one dependency. The arrow points along the reading direction, and the label names the relation, for example is blocked by or Predecessor.

The tree opens one level deep.

Use DEPTH to draw 1, 2 or 3 levels at once, or All. All stops at 6 levels. A very large tree stops at 600 items and says limit reached. Focus a card further out to continue from there.

Select Items in the tree header, search this board's planned and backlog items, tick the ones you want and select Draw tree (n). The picker opens with the current items already ticked, so you can add one more.

Open Direction to choose how the tree reads:

The tree starts on the option that matches your board's line-arrow setting, marked Board setting. Your own choice is remembered for you on this board. Picking the board's option again clears it.

Switch from Tree to List when you want the same dependency network in a compact, review-friendly table rather than a diagram.

Each row shows:

The tiles at the top count Blocked by, Blocks, Cross-team and Open. Rows are ordered by target date. A relates to link stored from both ends is shown once.

Double-click a row to edit the dependency.

The dialog opens on two slots: Choose the creator item and Choose target item. Select a slot to open the item picker. Nothing opens on its own.

The creator must always be an item of the PI Board you are currently working on:

Creator in the backlog: the board draws Kendis dependencies only between planned items. A backlog creator therefore needs a Jira or Azure DevOps link type. With a Kendis-only link type, the dialog explains why and Save stays disabled.

The receiver picker has three sources:

Search accepts a key, for example ABC-123 or 1042, or words from the title. Results are paged.

You can pick several receivers. Each becomes its own dependency, with the same link type and fields.

The dependency appears on the board and in the listing straight away. When you create it from the tree, the tree stays open and shows the new link.

Select Edit on a card, a line in the tree, a row in the tree's list or a dependency in the grid.

The edit dialog shows both items, the link type and all fields. The link type is locked once the link exists in Jira or Azure DevOps.

When you edit from the tree, the dialog opens over the tree and the tree stays open afterwards.

Select Delete from the card, the tree or the dialog. Kendis asks you to confirm.

For a dependency that also exists in Jira or Azure DevOps, tick Also delete the link in Jira or in Azure DevOps to remove it there too. Without the tick, the Jira or Azure DevOps link stays.

A dependency whose home is another board is deleted on that board.

The edit dialog has Conversations and Watched by tabs for stored dependencies. Add, edit and remove comments, and add or remove watchers. The comment count on the card updates straight away.

Cross-board dependencies still have one shared record. That record lives on its home board, while every other board that lists the dependency reads and edits the same summary, status, people, dates and comments.

The card and the tree show the home, for example Home: PI#21.

You can edit a dependency from any board that lists it. The save goes to the home board, with the home board's statuses and edit rights. Deleting is done on the home board.

When a home board closes, its record is preserved as history and is no longer changed.

The first time someone saves the dependency from an open board, Kendis continues it there as a new live record. The dialog tells you before you save, for example Saving continues this dependency on PI#22. The record on PI#21 stays as it was. The Jira or Azure DevOps link is kept as it is.

When the dependency's item is on several open boards, Change home in the edit dialog moves the record to another of those boards.

A Jira or Azure DevOps link synced to the board does not have a Kendis record until someone edits it. The first edit, from any open board you can edit, stores the record on that board, which becomes its home. The dialog explains this, for example This Jira link has no Kendis record yet. Saving stores it on PI#22, which becomes its home. Nothing is sent to Jira or Azure DevOps.

Open the settings icon in Dependency Tracking and select Dependency settings. The same settings are also in Edit Board Settings › Additional Settings.

This setting decides how the team of an item that is only in Jira or Azure DevOps is shown in the Outside this Board tab, the grid and the tree.

The setting applies to every Program Board on the same Jira account. Only company administrators can change it. Everyone else sees it read-only.

Users without edit rights do not see + Create dependency, the green + on tree cards, or Edit and Delete.

A useful dependency review should move from visibility to ownership to action.

Keep the dependency record current from the view you are already using: the listing, grid or tree. Update ownership, target dates, status and comments as the situation changes.

The key idea is continuity: the dependency stays connected even when the work crosses boards, teams and planning cycles.