An option that is at the very top of our configuration menu for a reason. It is one of the most important config menus as it allows to select recalculation methods used on Tasks displayed in Gantt chart, set up a progress configuration, Task link synchronization and more. It is highly recommended to go through this and all the following setup.
Configuring a Gantt
Gantt Configuration itself is divided into few key sections which are described and explained in each paragraph below.
Issue Limiter - Max Number of Issues Loaded
The first field is the maximum number of issues that can be loaded in Gantt chart and Gantt's WBS at loading time. This is tremendously helpful if you experience performance issues. By limiting the number of issues loaded at once, the system has less data to work with and can run faster than ever. Obviously, issues outside of the limit are available to the user by pressing the 'Load More' button which appears in such a situation. Each click loads the number of issues specified in this field. For instance, if you define 100 issues as the limit and have 700 of them in total, it will take 7 clicks to load all of them.
Task Period Configuration
In this section we are able to choose from app's recalculation methods for Task's Start Date Field and End Date Field. As our tasks must be displayed on the Gantt chart in some way, they do need those fields to be populated one way or another. Without them, the application wouldn't be able to locate the beginning and the end of a Task Bar. As there is no native Start Date of an Issue in Jira we have to specify one. It is configured as a Custom Fields ('Start Date' & 'End Date') by default.
As a general rule, everything set in the fields described below will be synced both ways. The default and recommended configuration is: 'SoftwarePlant's Custom Fields'. 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 will 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.
This is of course a specific situation when no days off were set in the 'Working Schedule' (which in Jira is set to 2 days by the default).
'Data Migration' is a feature which manifests itself when we try to switch 'Task Period Configuration' method in 'Gantt Configuration'. It is applied only to 'Start' and 'End' date fields. What does it do? It assigns new settings to data which already exist in Jira environment and our application shifting the type of the' Time Period Configuration' (from Start-End Dates recalculation to Due Date - Original Estimate and vice versa). The checkbox which enables this feature will only appear whenever the app recognizes that a change within these mentioned fields has been made. The operation of 'Data Migration' can be very time consuming and may highly affect the performance of our Jira environment. This is a direct result of the fact that during the migration process, the app has to recalculate and input new values to the structure of BigGantt and BigPicture and update each and every Jira issue.
Results of testing the 'Migration' feature look as follows:
During tests which we performed on Jira 7.4.0 which is stored on 3GB RAM machine with i7 2.26 Ghz processor and 256 GB memory SSD drive, a migration of 10 000 issues took about 7 minutes.
Before starting the Migration process it is crucial to make sure that following conditions are met:
All Programs are synchronised properly with a valid status (meaning that their mapped fields: Star / End date are properly populated in Jira). This can be done by accessing every program and waiting for the synch-up to start and successfully execute.
All tickets which are to be migrated need to be 100% valid, meaning all their required fields have to be filled out properly. If this condition is not met, it may cause the app to end up in an endless update progression state.
Jira backup was performed! This step is crucial, as in unlikely case of migration failure, this is the only way to recover the environment to its previous state (More information can be found in this Atlassian article)
Migration is being performed when Jira is not accessed by any other users than the one performing this action!
We have to remember that the migration may take some time (even few hours), depending on the size of the project and capabilities / specs of the device on which our environment is ran. During that time the screen does not implement and show any progression indicator, therefore to track a progress it is required to observe logs which will return an information on Migration being finished.
In case of any issues during or after the migration, please restore previously backed up instance od your Jira and contact the SoftwarePlant support team via our ServiceDesk.
This field stores Task Progress in numeric value starting from 0 (no progress) till 100 (task completed). We can map a variety of fields in this setup. The list of fields look as follows:
Story Points - Measurement of a complexity and/or size of a requirement.
Business Value - Measurement of a business value of a requirement.
Progress - Progress field used by SoftwarePlant plugins (BigPicture, BigGantt).
Scheduled Duration - Scheduled duration created by JIM (Jira Importers Plugin) during import process.
Days - Days created by JIM during import process.
Time Tracking Progress (timeTrackingProgress).
As we can see, this option allows user to select either standard Jira's 'Time Tracking' field, or a Custom Field value of our choice. Our app comes with its standard Custom Field called: 'Progress' which defines and allows to measure the Task Progress with scale 0 to 100. Each issue with values for Time Tracking or the Custom Field present will not only have its progress shown in the appropriate column on the left side of the Gantt chart, but also on its issue bar on the chart itself (darker shade of Task's color).
By dragging the small triangle on the Gantt's Task Bar to the left or to the right, we can quickly change the progress of such Task, much faster than by opening the Task and manually changing that value in Jira. Once we set the 'Progress' as an option, the value updated once we drag the slider/progress bar is our 'Remaining Estimate'. In order for it to get updated, we have to define this value, even if it was to stay at: "0", as the blank field is not allowed.
Task Baselines Configuration
In many cases Baselines can be very helpful! They are the "phantoms" or "footprints" of a Task. When set to 'ON' (for the whole chart or a given issue), if the user moves a Task on the Gantt chart, an opaque phantom of that Task will be visible in its initial position. This is very often used to track work progress and to confront the current state versus estimates. Users can configure the Start and the End Date of a Baseline (just like they can with Tasks, described above).
As we already know, our app is nested within Jira environment, therefore it is very dependent on its internal customization. Two aspects revolving around our Gantt Config, which need to be properly set in Jira itself are: Custom Fields and Issue Links. As per instructions in previous paragraph, we are now aware that Task's and Baseline's Start and End dates are custom fields predefined by the app in Jira environment. Same goes for Issue links. In order for issues displayed on the Gantt chart to be linked properly and to present a correlation between Tasks in Jira, a proper settings in both cases has to be applied in that environment.
App's Default / Required Custom Fields
When the app is installed, it automatically defines and sets up context for Custom Fields, which it will use. These custom fields are: Start Date, End Date, Baseline start date and Baseline End Date. The only thing we need to make sure about is that the available Context is set to Global (all issues). It also should be predefined, though we want to be sure that each aspect of our Jira is set properly in order for the application to work as intended.
We can do this by visiting Jira Administration (cog icon) → Issues → (FIELDS) Custom fields.
Task Link Synchronization and App's Dedicated Issue Links
Same goes for Issue Linking. When using the Gantt chart, users can click on tiny markers in form of a circle on each side of every element (Task, Milestone, etc.) and drag it to another in order to create a Task Link. This is a simple relationship, such as "Task A starts after Task B ends". Since two Tasks can be linked together, and each has 2 circles (one representing the start, the other representing its end date), there are four possible combinations:
Gantt: End to End Link
has to be finished together with →
has to be finished together with
Gantt: End to Start Link
has to be done before →
has to be done after
Gantt: Start to End Link
earliest end is start of →
start is earliest end of
Gantt: Start to Start Link
has to be started together with →
has to be started together with
The above presents a clean Jira instance with only our application. If you have other apps, you may see additional entries in the drop-down menu.
If Task Link Synchronization values are missing, they might have been accidentally removed . To reset link values, please go to the Jira Administration Panel (cog icon) → Issues → (ISSUE FEATURES) Issue Linking setup and enter values as below. They will be recognized by the app so you can select them in Gantt Configuration.