Dependencies

Link issues together, see what is blocking what, and read the slack on each blocking edge

Issues link to each other in Elixion, the platform for Engineering Intelligence™. A link records how two pieces of work relate; a blocking link additionally marks the blocked issue, and feeds the project's dependency view.

The relationship types

| Type | Reciprocal | |------|-----------| | Blocks | Blocked by | | Blocked by | Blocks | | Relates to | Relates to | | Duplicates | Duplicated by | | Duplicated by | Duplicates | | Clones | Cloned by | | Cloned by | Clones | | Causes | Caused by | | Caused by | Causes |

Hierarchy is not in this list. A parent and its subtasks, and an epic and its issues, are carried by the issue's own parent and epic fields, not by a link.

Clones is a link you set by hand between two issues that already exist. There is no clone action that copies an issue.

Adding a link

Open an issue, find the Relationships panel, and press Add Relationship. Choose the type, then search the project for the issue to link to. Links are within a project.

Two things happen when you save a blocking link:

  1. The reciprocal link is written for you. Saying "PAY-42 blocks PAY-58" also records "PAY-58 is blocked by PAY-42", so the two issues can never disagree about the direction.
  2. The blocked issue is marked blocked, with a reason naming the blocker, for example "Blocked by PAY-42".

Removing the link removes its reciprocal too, and recomputes the blocked flag. If that was the last thing blocking the issue, the flag and the reason clear.

Reaching Done also clears an issue's own blocked flag. Finished work is not blocked, whatever once held it up.

Cycles are refused

Elixion walks the blocking graph before it saves a blocking link, and refuses one that would close a loop. If PAY-42 already blocks PAY-58, directly or through any chain, you cannot make PAY-58 block PAY-42. You also cannot have two links between the same pair of issues, in either direction.

On the issue

The Relationships panel groups links by type and shows each target's key, title, status and priority, with a control to remove it.

Above the groups, two banners appear when they apply:

  • "This issue is currently blocked", with the reason.
  • A count of blocking relationships that may need resolving first.

Below, a Dependencies section lists the issues blocking this one. It shows the first three and expands to the rest.

The project dependency view

Dependencies in the sidebar opens the project wide view, headed "What's blocking what". It offers a List and a Graph of the same data, and a strip of three counts: Total, Blocking, Blocked.

The list is ordered risk first. It has an At risk section and an All dependencies section, each row reading upstream issue, relationship, downstream issue, and slack.

The graph draws the same links as nodes and arrows. A node that sits on a risk edge is outlined in the alert colour, and the legend names those nodes the critical path.

Slack, and what "at risk" means

Slack is the number of days between the upstream issue's due date and the downstream issue's due date. It is computed only for blocking links, and only when both issues have a due date. A row with no due date pair shows a dash rather than a number.

Negative slack means the work that depends on the blocker is due before the blocker itself is due. Those rows are the At risk section, and their slack is shown in the alert colour.

This is the most useful thing on the page, and it is free: put due dates on the two ends of a blocking link and the view tells you which chains cannot hold.

What links do not do

  • Typing "Blocks PAY-42" in a description or a comment does not create a link. Links are made in the Relationships panel. The only text Elixion parses for issue keys is a merged pull request's title and branch name.
  • Nothing is sent when a blocker is completed. The blocked issue's flag is recomputed when the link is removed, or cleared when the issue itself reaches Done.
  • Bulk actions cover update, transition, archive, unarchive, assign and labels. Linking is done one link at a time.

Working with dependencies

  • Link in the direction you are standing. From the blocked issue, "Blocked by". From the blocker, "Blocks". The reciprocal is written either way, so it makes no difference to the data and a lot of difference to how fast you get it right.
  • Use Relates to sparingly. A link that says nothing about order is a link nobody reads twice.
  • Date both ends of anything on the critical path. An undated blocking link is invisible to the At risk section.
  • Resolve blockers before you plan around them. A chain of four blocking links is four chances for a date to slip.

Next