Are you planning a migration to Cloud? Make sure you don't lose your BigPicture data/configurations in the process. Check out this page for information on how to migrate BigPicture's data to Cloud. If you have any questions please email email@example.com
Dependencies specify the relationships between tasks, milestones, and other items which can be presented on the timeline and can be displayed by the Gantt and Board type modules (Gantt and Board are the default module names used). By defining dependencies, you can not only automate task scheduling but also highlight relations between tasks without impacting the schedule. Keep in mind, that the items presented on the Gantt chart are system-wide, and changing their dependencies might affect tasks in other Boxes or connected tools.
The Gantt module takes linking to the next level and you can use non-Jira links to define dependencies between Issues and non-issues, such as Projects, Versions, Components, Sprints and Backlog, Checklists, etc. You can visualize up to five different links. Almost any native Jira link or custom link can be synchronized.
The Board module dependencies are color-coded so that you can easily find the tasks that need your attention.
The strong dependencies between tasks impact the scheduling of those tasks (does not apply to Soft links). Linked tasks will push and pull each other in time, according to the properties of the dependency between them. Those properties and their impact work as listed below:
Dependency type determines the direction of the dependency and also which of the Tasks' dates are relevant. We call them "relevant", because certain changes to those dates might cause either rescheduling of the dependant tasks or can be even impossible to perform (the app will immediately revert their task to the previously calculated dates). To get more information on which are those changes and what is their outcome, see the table at the bottom of this page. Changes of the dates that are not "relevant" do not cause rescheduling of this dependency (but might still cause changes to its parent's or children's periods).
Lag Time is the time period calculated in days dividing the linked tasks. Lag time has the highest priority over other Dependency properties. In both ASAP and non-ASAP modes, the lag time will be respected and applied regardless of other circumstances. The type of Dependency determines which date (Start or End) of the Source task the Lag Time will be added to.
ASAP mode always schedules Target tasks to take place 'as soon as possible', according to dependency type. This renders the Target task strictly dependent on the Source. Therefore it will be impossible to drag and drop it, neither to the future nor the past. The Target task will always revert to its position previously calculated by scheduling.
You can configure the link mapping in BigPicture configuration, Jira administration permissions are required to access this section.
The mapped links can synchronize with Jira but you can also create links between Jira issues and non-Jira issues such as Basic tasks, Projects, Versions, Components, Sprints or Backlog, or Trello tasks, in which case such a link will be visualized only as, for example, there are no project links in Jira.
Displaying of dependencies varies based on a module:
Asap mode (available only for strong dependencies)
There are four standard types of dependencies which are called 'Strong link' and have a scheduling impact. Every task on the timeline has two significant sides - to the left and to the right. These signify the Start and End Dates. Therefore, by linking two tasks (below referred to as Task A and Task B) we can expect four following combinations which are referred to as dependency types.
When one of the Auto scheduling modes is enabled, such links will adjust the linked task's period. Strong links are displayed as a regular line and you can use them to indicate when a task should begin or end in relation to other tasks.
The default strong links are created during the installation:
In case there are multiple dependencies targeting one task, including ASAP dependencies, the latest possible date will be set for this task.
End to Start
When Task A finishes, then Task B starts and Task B can’t start until Task A is done.
Asap mode off: 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.
Asap mode on: moving Task A to the left or right will also move Task B, so that it starts on the first working day after A finishes. Moving Task B has no effect.
End to End
Asap off: when Task A ends, Task B also immediately ends. Task B can’t finish until Task A is done but they don’t have to end at the same time: Task B can end any time after Task A ends. The lag time determines the minimum gap. 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.
Asap on: when Task A ends, Task B also immediately ends. Task B can’t finish until Task A is done but they don’t have to end at the same time: if the lag time is set it determines the gap between the Task B end and Task A end. Moving Task A to the left or right will also move Task B so that the gap between the tasks is equal to the lag time set.
Start to End
Asap off: 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.
Asap on: when Task A starts, Task B can’t finish until Task A begins. Moving Task A to left or right moves the Task B so that it ends on the start date of Task A (+- lag time). Task B is not movable.
Start to Start
Asap off: 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.
Asap on: when Task A starts, Task B also immediately starts. Task B can’t start until Task A starts but they don’t have to start at the same time: if the lag time is set it determines the gap between the Task B start and Task A start. Moving Task A to the left or right will also move Task B so that the gap between the tasks is equal to the lag time set.
Soft links are just information about a dependency between the tasks and have no scheduling impact. By default, Soft links are not visible as this type of link is dedicated to showing dependencies using the Board module. Such links are displayed using a dashed line:
External links show dependencies between tasks within the scope of different Boxes.
External dependencies are listed in the dependency dialog. They are marked with a crossed-eye symbol because they can't be visualized.
Scheduling mode vs strong dependencies
Strong dependencies do NOT affect auto bottom-up tasks (if the child tasks conflict with the change).
An auto bottom-up task can have children nested underneath it in the tree structure. In this situation task period is limited by the periods of its children (won't be affected by a strong dependency, if there is a conflict):
Possible changes to make a strong dependency affect the tasks:
changing the scheduling mode of the parent to top-down:
drawing the Strong dependency to a child under the auto bottom-up parent (moving the child will expand the parent, but not move it). Before: