As our add-on functions within Jira, it uses the same concepts of workload units as the environment it operates in. And as there is a variety of other Jira issues which are not Tasks, they have to be somehow represented on the Gantt chart. In this article, we will learn what can be displayed on our application's Gantt chart, what is a Task in our app's terminology and what operations can be performed on these units.
What Can Be Synchronized?
Our plugin can easily recognize and synchronize and display the following entities:
- Jira Issues
- Other Jira Non-Issue concepts like: Versions, Components, Projects, Agile Sprints, Backlog
- Artificial Tasks
Example of such update made by app user:
Real time integration between Gantt and Jira
Every drag and drop action made on the Gantt chart will immediately affect corresponding Jira issue in Jira. Depending on the Global configuration, drag and drop can affect custom fields, Due date or Original estimate.
Jira Cloud misconfiguration preventing editing Jira issues
Jira Cloud is a platform which puts a strong emphasis on making data access and data changes as secure as possible. Due to this, a restrictive set of configurations needs to be done by the user, which is not obvious and is a mundane task to administer.
To overcome this configuration hurdle, only on Jira Cloud version of our apps, we have implemented a mechanism which executes an update on a Jira issue as the app's technical user.
Visible effect of this change is a new type of entry in the history of the Jira issue which instead of the current user, will have the app user as the author of the change.
A Concept Of an Issue And a Task
In Atlassian's Jira related documentation we can find the following description of a Task: "A task is a unit of work contained within a story. ; In JIRA Agile, individual Tasks are represented as Sub-Task issues, and stories are represented as (parent) issues." As we can see a Jira task is just a one of the issues among the selection of other pre-defined issue types and these which can be custom-made by a Jira user. Following the above definition we can distinguish many types of Jira segments - issues and even concepts which are not defined as issues, like Versions, Components, Sprints etc.
Once again, as per Jira Knowledge Base: "JIRA can be used to track many different types of issues. The default types are listed below, but please note that your JIRA administrator may have customized this list to suit your organization.
- Bug - A problem which impairs or prevents the functions of the product.
- Improvement - An enhancement to an existing feature.
- New Feature - A new feature of the product.
- Task - A task that needs to be done.
- Custom Issue - Acustomissue type, as defined by your organization if required.
All the above are integrated part of our Jira Projects. If the Gantt chart represents a project in form of a diagram of tasks on a timeline, then it has to manifest different concepts of Jira issues on its timeline as tasks... And it does. Almost every single piece of information which Jira defines on the Gantt chart can be represented in a form of a Task in our app's definition. If the structure which we maintain is broad, then tasks (in Jira terminology) will usually (not always) be Sub-Tasks - children to parent tasks which in reality are: Epics, Stories or even whole Jira Projects!
A concept of an Artificial Task
Now this is new! What are Artificial Tasks? They are nothing more but tasks added to the app's - Gantt chart (and columns of Gantt's WBS Waterfall Panel) yet not reflected in Jira whatsoever. They can perfectly coexist with Jira issues presented on our Gantt chart and on Gantt's WBS like the rest of Jira's native tasks and go under the same set of rules (including linking, sorting etc.). We can create and set Artificial Tasks to be visualized asa regular tasks or application's Sub-Tasks.
Artificial Tasks can be arranged into Templates in the Program Configuration panel. They make great placeholders, temporary tasks and are useful in many other scenarios. Our Program cloning mechanism uses them to replace Non-Issue Jira entities (like Components, Versions, Projects) which it is unable to recreate in Jira while building a new Program.
Creating Data Content: Tasks and Sub-Tasks
It is possible to create standard Jira issues from the app itself. Depending on the selected option, Task can be recorded as a standard Jira Issue or Sub-Task Jira Issue. Our application gives us the flexibility to even create a task that is dependent (as a child) in Gantt chart, but inJirait is recorded as a standard issue.
We can add tasks to our Jira Project and BigGantt / BigPicture Program by selecting'+ Task' drop-down menu. The first thing that hits us right after accessing this menu is a possibility to either Create a task or a Sub-Task. Now here's the trick as few different task types can be created.
If we decide to add a Task with no Start and / or End Dates, the app will pick the Original Estimate value as its default and place it starting from today, unless of course, its creation took place in the past, in which case, the creation date will be used. Following this logic, if no Original Estimate value is present, the app shall treat the creation date for Start Date and when the End Date is empty, then it picks the resolution date (if the issue was Resolved) instead. This usually means that a Task will be set as a 1-day Task for today unless the Task was resolved a while ago and just recently imported into our application. With Original Estimate mapped as the Start or End Dates, it will represent the duration of a Task. For example, a Task starting on the 1st with 7 days of Original Estimate will end on the 7th. Likewise, a Task ending on the 5th with Original Estimate of 6 will always start on the 1st day of a given month.
What sorts of tasks can be created then?
- JIRA Task - This will open Jira's 'Create Issue' dialogue box that will allow us to enter a series of values. Only fields marked with a red asterisk (i.e. Project, Issue Type, etc.) are mandatory. Other fields are optional and can be left blank. Once we click on the 'Create' button the task will be automatically added to the Gantt chart, a Gantt's WBS, and most importantly - to Jira itself.
- Artificial Task - Will bring up a pop-up window with issue's Summary, Start and End Dates. Filling out these fields, followed by pressing the 'Save' button will automatically allocate the Artificial Task on the Gantt chart and on the Gantt WBS, yet will not affect our Jira instance.
- Task Template - This feature will return us to the Task Template Creation menu in the Program Configuration.
Every time we'd like to create a Sub-Task, we have to highlight it by clicking on its potential Parent Task on the Gantt's WBS and depending on the type of Task which we click on, then we will be able to create the following:
- Gantt Sub-Task - This will open Jira's 'Create Issue' dialogue box that will allow us to enter a series of values. Only fields marked with a red asterisk (i.e. Project, Issue Type, etc.) are mandatory. Other fields are optional and can be left blank. Once we click on the 'Create' button the task will be automatically added to the Gantt chart and a Gantt's WBS as a Sub-Task, and to Jira environment as a regular task.
- Jira Sub-Task - This will open Jira's 'Create Issue' dialogue box that will allow us to enter a series of values. Only fields marked with a red asterisk (i.e. Project, Issue Type, etc.) are mandatory. Other fields are optional and can be left blank. Once we click on the 'Create' button the task will be automatically added to the Gantt chart and a Gantt's WBS as a task, and to Jira environment as a Sub-Task to another issue.
- Artificial Sub-Task - Will bring up a pop-up window with issue's Summary, Start and End Dates. Filling out these fields and pressing 'Save' button will automatically allocate the Artificial Task on the Gantt chart and on the Gantt's WBS as a Sub-Task to another task, yet will not affect our Jira instance.
In case of JiraSub-Taskit is worth mentioning, that the Issue on which we click has to be capable of having a Sub-Task (meaning - it cannot be a Sub-Task itself).
Latest version of the plugin (BigPicture Cloud and BigPicture 7.2.0 and above) introduce new mechanisms which reschedule start and end dates of each Gantt task.
Auto bottom-up mode
This mode is designed for planning which first, defines bottom WBS elements and then adds top WBS items to group them, e.g. grouping existing Stories and Tasks with Epics to see the projection of the Epic delivery date based on all Tasks and Stories related to the Epic.
Tasks will behave according to following rules:
- Parent in "auto bottom-up" mode adjusts it's children i.e.
a. start date of the parent = minimum of children's start dates
b. end date of the parent = maximum children's end dates
- If the parent in "auto bottom-up" wants to adjust dates of its children but superior element in WBS does not allow it, then the children may not be allowed to change start or end date.
Auto top-down mode
This mode is designed for planning which first, defines top WBS elements and then adds lower WBS items, e.g. planning Epics first and the adding Stories underneath them.
- Parent in "auto top-down" puts boundaries on it's children start and end dates i.e. :
a. start date of any child >= start date of the parent
b. end date of any child <= end date of the parent
Resize of the parent task
Effectively, manual resizing of the parent task is possible only in auto top-down and manual task modes.
Moving parent task
- Moving the parent by x days moves children by x days in the same direction.
- Moving the parent never moves children in "lock" or "manual" mode.
Task modes - matrix with detailed rules and outcomes
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?
Yes, by either
Yes, by either
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:
- system checks working days of assignee (individual resource) that allows assignee to complete the task based on:
- resource's Holiday Plans and Workload Plans
- task start date
- task duration
- system calculates a correct start date of the task
- in case a task start date is a non-working day, system finds the earliest possible working day that comes after task start date
- system calculates a correct end date of the task
- 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).
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 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.
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 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 Links
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:
- Outdent the task, so it moves to the same tier as its previous parent.
- Move the task down so it's just below the new parent.
- 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.