This article outlines the most essential configuration steps required start using the App and provides guidance and best practice on the most common use cases.
Make sure that the version of the App you want to install is compatible with your Jira instance. We recommend using the Atlassian's plugin manager which will always install the latest compatible version of our App. If you plan to use the app together with BigPicture Enterprise or BigTemplate, make sure they are compatible as well.
Before installing the app on your production instance make sure to test it using the staging environment. If it is not possible, create a separate project on your instance and test how the App works.
The first step should be to identify the business processes that will be affected by BigPicture and to develop, at least at a high level for piloting purposes.
There are administrator level settings in BigPicture - the Jira administrator on the company side should be included in the BP installation process.
We strongly recommend that you go through the documentation, especially the cross-module features and scheduling rules.
Test it first
As with all new software installations, we recommend using a stage instance to test it first and to backup your data before installing on a production instance.
Start with the App's Technical configuration which requires Jira administrator access. The most important are the following:
- Security - if you are evaluating the App, you can grant permissions to everyone or restrict access by assigning security roles to users or user groups.
Tasks - specify which fields will be synchronized when using the App. Each task has a start and end date and it can be mapped to different fields. If your are already using date fields in Jira (such as 'Due date') simply map them and the App will use those dates during the synchronization to generate the tasks correctly.
The start and end dates are required by the App to generate the task on the timeline. When task without date estimates are synchronized, the App will use the "Creation date" as both the start and end date mapped field values. If the tasks dependencies are defined this might result unintentional updates of schedules.
Besides the task fields mapping, we recommend disabling the comments and notifications. While they are very useful and improve the communication, when you create your Boxes and synchronise existing data, users might receive numerous notification emails. Enable these features once your Boxes are synchronized.
Link configuration - like with the task fields mapping, you can synchronize up to five different link to visualize the task dependencies.
- Resources - Teams are a very important element especially when using the Board and Resources modules. Make sure to select the fields used for Team assignment.
- Risks - check if your Risk heat map matches your organization's needs - change the field mapping or update the select options if required.
The administration section is another important area and it requires App administrator access:
- Security - grant access to the App. There are two global security roles - App users and App admins.
- Box Types - configure the default setting of you Boxes.
BP has a so-called Period mode functionality that can influence the length of parent ribbons and/or child ribbons. As a precaution, it is best to set the 'Manual' period mode mode before the Box scope is defined. BP gives you the ability to set up an automatic record of actions performed on a given ribbon and send notifications to an email to Jira users. In case of unforeseen events, a large number of emails can be sent to the mailbox
Golden rule: at the beginning of the road with the App, remember not to throw all of Jira issues into the scope. It can be quite easy to make a mistake, e.g. if you have incorrectly written JQL when defining the scope of a Box.
There is no 'UNDO' button in Jira, so make changes very consciously, especially when you define the scope of a Box and synchronize data. We do recommend to test the App in a safe test environment.
Depending on the configuration of the App, your tasks might get updated or recalculated during the synchronization, for example, once the scope is defined. By default, the App requires two points on the timeline (in other words two dates) to generate a task bar and determine the start and end points. Those points in time are the task's 'Start date" and 'End date' and are stored as 'Start date' and 'End date' custom fields by default.
If a Task with no Start and / or End Dates is added to the scope of a Box, the App will pick the Original Estimate value to calculate the duration and set the task's Start date to Creation date.
Following this logic, if no Original Estimate value is available the app will again use the creation date as 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 duration starting on the Creation date. With Original Estimate mapped as the Start or End Dates, it will represent the duration of a Task.
As a consequence, in such a scenario, the task mode will be applied to tasks with empty date fields to avoid data corruption when the task are structured automatically using presets.
In the case of Sprint and Version tasks synchronization, the 'Auto top down' is used by default.
Read more about the scheduling and synchronization settings in the Scheduling section.