Configuring the link

Clicking the 'Link Arrow' opens a dialogue box which allows you to edit the link's behaviour. For every link on Gantt there is a possibility to determine:

• Lag Time,

• Link Type

• Link Mode (ASAP)

or you can delete the link.

Lag Time

Lag time is the time period calculated in days dividing the tasks linked. The tasks are recalculated according to their types when their current position indicates time gap grater or shorter than the Lag time set for that particular link. If the value is a positive number the tasks will be separated by the given number of days. If on the other hand the Lag time is a negative value than the tasks will 'overlap'. The Lag time period set is honoured whenever it makes sense.

Example: If the lag time between Fitt the windows and Paint the wall is set for 2 days than Paint the wall cannot start before Fitt the windows but if it starts more than 2 days later than the lag time condition is still met. The lag time between tasks linked with Start to Start is not corrected as it is in accordance with Start to Start link type definition above (Task B can begin any time after Task A begins.).

ASAP mode

Once this checkbox is marked the link will always set:

• the earliest possible Start Date of the linked target task if Start Date is the target

• the earliest possible End Date of the linked target task if End Date is the target.
  

In other words - link in ASAP mode always schedules target task as soon as possible based on dependency type. There are no restrictions on how many links are created for each source or target task as long as they are not crating circular relationship (discussed here). If a task is moved to a prohibited position (based on link type and mode) it is moved back/forward to the appropriate position.

Example: Once you start Pour the concrete task you want the Level the concrete task to start immediately. Such ASAP link will be marked by golden colour.

Deleting Dependency

There is of course also the possibility to 'Delete' the link. The operation cannot be undone and there is no "confirm" prompt. Once a link is deleted only a new one can be created in its place.

Link colours

The colours encode the configuration of the links, lag time and type of tasks that are linked. It is meant to make it easy to distinguish at a glance how the tasks are scheduled.

Jira Tasks Links

Jira tasks with ASAP links but without Lag Time are displayed in golden colour.

Jira tasks with ASAP links and with Lag Time set are displayed in Blue colour.

Jira tasks without ASAP links and without Lag Time are displayed in Gray colour.

Jira tasks without ASAP links but with Lag Time set are displayed in Violet colour.

More complicated cases

In more complicated cases when:

• multiple links target single task and

• links mode is selected as ASAP

system sets the latest possible date that honours all links applied to the task and the Lag time.

In practise, when we take a look at the case presented in the figure above, it is set the earliest date of the task PVIII-24, but it takes into account all links applied (from both task PVII-27 and task PVII-28)

Loops and Cross-Program Relationship

In Jira, issue links have no effect over the environment's structure and behaviour. That means we can create any type of dependency between them in various combinations. Even a type of dependency that would make no logical sense or would end up in a paradox can exist in the vanilla Jira environment. In our application though, links have a direct effect on the Start and End Dates, so some combinations of links will not be allowed. This concerns what we call "loops". Let's imagine the following type of inter-dependency:

Task A (Ends) → (Starts) Task B

Task B (Ends) → (Starts) Task A

Such a combination of links on these 2 tasks would result in Task A rescheduling Task B, Task B rescheduling Task A, Task A rescheduling Task B, and so on and so forth. This sort of paradox would create an infinitive number of data re-calculation and could possibly crush our environment. This is why our app will not allow it and will return a Warning.

Loops are very easy to detect if tasks belong to a single Program. However, at times we may meet a situation when the same task is a component of various - multiple Programs, each belonging to a different user. We could cause a change that might reschedule their whole Gantt, sometimes even not realizing it (i.e. once permissions to their Program were not granted to us).