Initial guide for administrators

This article outlines the essential configuration steps required to use the App and provides guidance and best practices 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 Atlassian's plugin manager, which will always install the latest compatible version of our App.

Before installing the app on your production instance, test it using the staging environment. If not, create a separate project on your instance and test how the App works.

Process identification

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, and the Jira administrator on the company side should be included in the BP installation process.

Documentation

We strongly recommend you review the documentation, especially the cross-module features and scheduling rules.

Test it first

As with all new software installations, we recommend testing a stage instance first and backing up your data before installing it on a production instance.

Configuration

The app has a minimal resolution of 1280x720. If you narrow the viewing tab, the view cannot be further compressed, and part of it will be cut off.

Start with the App's 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.
Task—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 you 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.

Note

The App requires the start and end dates to generate the task on the timeline. When tasks without date estimates are synchronized, the App will use the "Creation date" as the start and end date mapped field values. If the task dependencies are defined, this might result in unintentional updates of schedules.

Besides the task field mapping, we recommend disabling the comments and notifications. While they are instrumental and improve communication, users might receive numerous notification emails when you create your Boxes and synchronize existing data. Enable these features once your Boxes are synchronized.

Dependency configuration - like with the task field mapping, you can synchronize up to five different dependency types to visualize the task relationships.
Team field configuration - Teams are an essential element, especially when using the Board and Resources modules. Make sure to select the fields used for the Team assignment.
Risks - check if the Risk heat map matches your organization's needs - change the field mapping or update the select options if required.

Administration

The administration section is another critical area, and it requires App administrator access:

Security Global roles in Administration - grant access to the App. There are two global security roles - App users and App admins.
Box types - configure the default setting of your Boxes.

Automation

BP has a so-called Scheduling mode (previously period mode) functionality that can influence the length of parent ribbons and/or child ribbons. As a precaution, setting the "Manual" period mode before the Box scope is defined is best. BP allows you to automatically record actions performed on a given ribbon and send notifications to an email address to Jira users. In unforeseen events, many 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's issues into the scope. It can be pretty easy to make a mistake, for example, 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 recommend testing the app in a safe test environment.

Depending on the app's configuration, 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 taskbar and determine the start and endpoints. 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 the Creation date.

Following this logic, if no Original Estimate value is available, the app will again use the creation date as the 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 the 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 period mode will be applied to tasks with empty date fields to avoid data corruption when the tasks 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.