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 thisarticlewe 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 conceptslike:Versions, Components, Projects, Agile Sprints, Backlog
- Artificial Tasks
A Concept Of an Issue And a Task
In Atlassian's Jira related documentation we can find a followingdescription 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 justa 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 abovedefinition 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 organizationifrequired.
All the above are integrated part of our Jira Projects. If the Gantt chart represents a project in form ofdiagramof 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 Jiradefines onthe 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
Nowthis 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 regularTasks 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) inGanttChart, 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 ispossibilityto 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 Startand / orEnd 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' dialog box that will allow us to enterseries 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' dialog box that will allow us to enter 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' dialog box that will allow us to enterseries 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).
We have already mentioned task basedlinks, 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 highlighta desiredtask, 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 theright,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'sbehaviour. 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.
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.
Thecoloursencode 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
systemsets the latest possible date thathonours all links applied to the task and the Lag time.
Inpractise, 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 andbehaviour. 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 createan infinitive number of datare-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'sdiagram,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 andoutdentations, 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 Artficial) 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.