We have already mentioned task based links, their synchronization configuration and types of links dedicated to our module in our article dedicated to the Gantt Configuration. But how do they really work? How do we put the knowledge to practice?
One on the Gantt charts timeline, when we highlight a desired task, small circles to the left and right side of that task will appear. Dragging the circle from one task to another and dropping it onto the task will create a dependency between these two tasks. Once the link is created, it will be reflected in Jira (and the other way around - link created in Jira will be displayed on the Gantt chart).
We can only perform a single drag and drop operation at a time, and each task (the one we start at and the one we end at) has two sides. This means there are four kinds of visual links (in a form of an arrow).
Every task on the Gantt chart has two significant sides - to the left and to the right. These symbolize the Start and End Dates. Therefore, by linking two tasks (below referred to as the Task A and Task B) we can expect four following combinations which are link types.
End to Start
Source: Task A end date → Target: Task B start date
When Task A finishes, then Task B starts. Task B can’t start until Task A is done. This is the default link type in Project, and the most commonly used.
Moving Task A to the right will also move Task B, as long as Task A's End Date is moved up to or ahead of Task B's Start Date. Moving Task A to the left has no effect on Task B. When Task B is moved to the left, it will not go further than Task A's End Date. Moving it to the right has no effect on Task A.
Example: Dig foundation (Task A) must be complete before your team can start Pour concrete (Task B).
End to End
Source: Task A end date → Target: Task B end date
When Task A ends, Task B also immediately ends. Task B can’t finish until Task A is done. They don’t have to end at the same time: Task B can end any time after Task A ends. Moving Task A to the left changes nothing. However, if Task A is moved further than Task B's End Date, Task B will be moved in order to retain the dependency (and to end at the same time). Moving Task B to the left further than Task A's End Date will automatically move Task B's end at the same time as the end of Task A. Moving Task B to the right has no effect on Task A.
Example: Your team is adding the wiring to the building and inspecting it at the same time. Until Add wiring (Task A) gets done, you won’t be able to finish Inspect electrical (Task B).
Start to Start
Source: Task A start date → Target: Task B start date
This means that when Task A starts, Task B will also start. Task B can’t start until Task A starts. They don’t have to start at the same time: Task B can begin any time after Task A begins.
When two tasks are connected this way and task A is moved to the left, task B remains unchanged. When Task A is moved right and exceeds the Start Date of Task B, then Task B will also be moved to the right in order to start at the same time as Task A.
When Task B is moved to the left, it will never go further than the start date of Task A. If Task B is moved right, Task A remains unchanged
Example: To save time, you want to level concrete at one end of the foundation while it is still being poured at the other end. But Level concrete (Task B) can’t start until Pour concrete (Task A) has also started.
Start to End
Source: Task A start date → Target: Task B end date
When Task A starts. Task B can’t finish until Task A begins. Task B can finish any time after Task A begins. This type of link is rarely used.
In this type of dependency, when Task A is moved to the right, if its Start Date exceeds the End Date of Task B, B will be also moved right. Moving Task A to the left changes nothing.
Example: The roof trusses for your building are built off-site. You can’t finish Assemble roof (Task B) until Truss delivery (Task A) begins.
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:
Link Mode (ASAP)
or you can delete the link.
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.).
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.
Please Note that depending if the task is ASAP or not the colours will change (discussed here).
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.
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.
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.
Artificial Tasks Links
Artificial tasks with ASAP links but without Lag Time are displayed with a dotted line in Golden colour.
Artificial tasks with ASAP links and with Lag Time set are displayed with a dotted line in Blue colour.
Artificial tasks with without ASAP links and without Lag Time are displayed with a dotted line in Grey colour.
Artificial tasks with without ASAP links and with Lag Time set are displayed with a dotted line 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).
Global configuration update
The Asap mode checkbox determines whether all newly created links should have the ASAP mode checked by default. It is important to note here that this operation does not migrate existing links to ASAP mode.