Content
 BigPicture

About BigPicture

BigPicture installation

Quick start with BigPicture

BigPicture Export

Tutorials and tips

Integrations

 BigPicture release notes

BigPicture Cloud Backlog

 BigGantt

About BigGantt

BigGantt - Important Notice

BigGantt installation

BigGantt Cloud Backlog

 BigGantt release notes

Shortcuts
 Release notes
 BigPicture
 Jira Cloud

 Jira Server

 Trello

 BigGantt
 Jira Cloud

 Jira Server

 BigTemplate
 Jira Cloud

 Jira Server

 BigPicture Enterprise
 Jira Cloud

 Jira Server

Knowledge Base

Tutorials and tips

Search


Task modes - matrix with detailed rules and outcomes

Mode

Is task affected by changes in other tasks or links?

Is task affected by changes in working days calendar?

Does moving the task affect children?

Is start/end date of the task editable/movable?

LockNoNoYesNo
ManualNoNoNoYes
Auto top-down

Yes, by either

1. parents

2. links

YesYesYes
Auto bottom-up

Yes, by either

1. parents

2.children

3. links

YesNoYes

Calculating tasks period based on assignee's working days

Please note, that calculating tasks period based on assignee's working days applies only to the tasks that are not parent tasks in WBS structure.

The reason for such a limitation is that parent tasks can be automatically recalculated based on its children periods which may be in contradiction with working days of a resource assigned to the task.

If an option "Calculate tasks based on assignee's working days" is switched on, a system calculates task period based on assignee's working days and ignores global Working schedule. Such a scheduling is executed according to the following rules:

  1. system checks working days of assignee (individual resource) that allows assignee to complete the task based on:
    1. resource's Holiday Plans and Workload Plans
    2. task start date
    3. task duration
  2. system calculates a correct start date of the task
    1. in case a task start date is a non-working day, system finds the earliest possible working day that comes after task start date
  3. system calculates a correct end date of the task 
    1. system checks consecutively assignee's working days that fits task duration until task can be fully completed

In case system cannot determine correct task period because assignee has no working days in the future, system falls back to global Working schedule to determine task period (the same way as if task is unassigned).

Linking Tasks

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:

  • 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 creating 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). Also, marking the link as ASAP does not change the default setting for every new link to be ASAP link. The configuration setting to set default mode to ASAP for links is explained 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.

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 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 Bluecolour.



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

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


Artificial tasks with ASAP links but without Lag Time are displayed with a dotted line in Goldencolour.

Artificial tasks with ASAP links and with Lag Time set are displayed with a dotted line in Bluecolour.



Artificial tasks with without ASAP links and without Lag Time are displayed with a dotted line in Greycolour.

Artificial tasks with without ASAP links and with Lag Time set are displayed with a dotted line in Violetcolour.


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 on 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 are-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).


Task Structure Adjustment

There's a number of ways we can adjust the structure of tasks on our Gantt chart and Gantt's WBS. One of our app's core features - its capability to alter tasks' values by moving them around with simple drag and drop mechanics can be used not only in the sphere of our Gantt's diagram, but also on the Gantt's WBS. This way we can adjust the allocation of tasks in the Hierarchy.

The other method is the method of manual indentation and is also very useful once we set our desired Hierarchy per Program and want to adjust it. We need to remember that our 'Hierarchy Adjustment Arrows' work per Program only (meaning they are not actually reflected in Jira) and can be easily overwritten whenever we will make Hierarchy adjustments in our Program Configuration.


Up and down arrows simply move a task inside its current node. For instance, if a task is a subtask of an Epic, we will only be able to move it up and down inside this Epic's tier.

Left and right arrows are responsible for indentations and outdentations, meaning to shift tasks into Sub-Tasks or parents of ones that follow.

As a result, if we would like a Sub-Task to go under a different parent, we need to follow this procedure:

  1. Outdent the task, so it moves to the same tier as its previous parent.
  2. Move the task down so it's just below the new parent.
  3. Indent the task.

Task Context Menu

As we will learn in articles on View and Data Filtering and Data Display and Editing on the Gantt chart, many task-based data and display operations can be applied globally (for each task in the whole Program / Gantt). Yet there are cases in which we would like to apply such adjustments for each task separately. This is what Task Context Menu is for. It allows us to create its Baselines or shift it to a Milestone, display its Details or manually change its Color, apply its Mode and desired Sorting method.

Other Task Operations - Related Articles

This article is just an introduction to basic concepts of Tasks and operations that we perform within the Gantt diagram on the daily basis. There's a much wider selection of actions which can be performed on Tasks (both Jira and Artificial) on Gantt chart along with its Gantt's WBS, though due to the nature of these actions - either Data Filtering and View or Display Edition related, they have been elaborated in other articles dedicated to those aspects.