Support for Atlassian Server Products (and apps like BigPicture) is ending in February 2024.

Are you planning a migration to Cloud? Make sure you don't lose your BigPicture data/configurations in the process. Check out this page for information on how to migrate BigPicture's data to Cloud. If you have any questions please email



The actual or planned workload of the individual resources or a Team. The effort expressed as the time or number of Story Points required to complete a task is evenly distributed over the task's duration.


To assess the performance of your project over time, you can set Baselines and track deviations from your initial schedule. 

The Baselines can be synchronized with Jira (Tasks requires Jira Admin permissions) and the synced fields can be added to Column views or as fields to the Task / Risk Cards.

You can create and delete Baselines for all the tasks in the scope of the Box or for selected tasks only. They are displayed as bold lines, showing the position of the task at the moment of creating the Baseline.

Basic task

Basic tasks are stored by the App and are NOT synchronized with Jira or other connected tools like Trello. Basic tasks can be viewed only using the App's Gantt, Scope, Board modules, or the WBS Widget. 

They can coexist with other tasks and work great as placeholders or temporary tasks and simulate higher levels in the hierarchy or serve as additional information box.

The App uses them to replace non-issue Jira entities (like Components, Versions, Projects) which it is unable to recreate in Jira while cloning the scope.


The most basic element of the App. Boxes are high-level task containers arranged into a hierarchy. 

A Box is a container for tasks - tasks can come from external tools, such as Jira and Trello. Basic tasks are native to the App and don't exist anywhere outside of it. 

Each Box has its own configuration (security settings, scope, modules). Depending on the setup, Boxes let you perform various actions and visualize data. 

Box hierarchy 

A tree structure consisting of a Box root (parent node) and Boxes (nodes). Each node can potentially have a different Box type.

The hierarchy is presented in the Hierarchy and Timeline modes of the Overview module as well as in the Box Switcher.

How the hierarchy can be arranged depends on Box type settings - possible parents are defined for each Box type. Additionally, scope type settings validation is performed when a Box is created or moved

Box type

Box template which defines most relevant characteristics of a Box (node), such as:

  • types of parent Boxes under which a Box of a given type can be nested
  • default module configuration and names
  • default column view of different modules
  • default card layout
  • default Period mode

Box types can be defined by BigPictures administrators. Read more here.

Box module

The following modules are available in BigGantt:

  • Overview
  • Gantt

The following modules are available in BigPicture:

  • Overview
  • Gantt
  • Risks
  • Roadmap
  • Board
  • Calendar
  • Resources 
  • Teams

Most of the modules can be preconfigured using Box types.

Box switcher

The Box switcher is a mini version of the Hierarchy mode of the Overview module. It shows the Box names and the hierarchy.

Use the Box switcher to easily shift between different Boxes. Once opened, the active Box will be highlighted so you can easily switch to a sub-Box or a different Box.

You will be able to browse only the Boxes to which you have permissions (you can't see a box that you can't access).

The Box switcher is displayed in the Apps header for each module and in the WBS Widget and Skill Widget which can be added to the issue screen.

Box status

Box status is displayed next to the Box name in the Box switcher. You can change the Box status in different sections of the app. In the Overview module using the right-click or by drag and drop when in Kanban mode. You can also change the status using the Board module. You can change the status of sub-Boxes from the Scope definition page (Box configuration).

The status is indicated using colors and The following color-coded statuses are available:

  • Not started - gray
  • In progress - blue
  • Done - green


The App calculates individual and team capacity. 

The capacity of your resources is calculated based on Workload Plans and non-working days resulting from Holiday Plans and individual /wiki/spaces/BIGGANTT/pages/315393385. It reflects the workload resources are capable of after everything has been taken into consideration. 

Column views

Column Views allow you to add different fields as columns to the task list and configure their display and aggregation settings which determine how data is presented in the Gantt and Scope type module's task list.

Connected tools

The App can connect different tools to your Jira instance. These include tools like other Jira Cloud instances, Trello or MS Azure (coming soon). The connection field (status) informs you if your instance was already connected.

Context Box

A Box which you are currently viewing. The Box name and its status are displayed in the Box Switcher.

Critical path

The critical path is the longest sequence of tasks that determines the project duration. This feature highlights all the tasks on the critical path with the red color. Tasks on the Critical path will also be listed in the Gantt Infobar.

To highlight the entire sequence, you must define dependency links between tasks. Only the strong links that impact scheduling will determine the tasks on the critical path.


Dependencies specify the relationships between tasks, milestones, and other items which can be presented on the timeline and can be displayed by the Gantt and Board type modules (Gantt and Board are the default module names used). By defining dependencies, you can not only automate task scheduling but also highlight relations between tasks without impacting the schedule. Keep in mind, that the items presented on the Gantt chart are system-wide, and changing their dependencies might affect tasks in other Boxes or connected tools.

The Gantt module takes linking to the next level and you can use non-Jira links to define dependencies between Issues and non-issues, such as Projects, Versions, Components, Sprints and Backlog, Checklists, etc. You can visualize up to five different links. Almost any native Jira link or custom link can be synchronized.

The Board module dependencies are color-coded so that you can easily find the tasks which need your attention.

The strong dependencies between tasks impact the scheduling of those tasks (does not apply to Soft links). Linked tasks will push and pull each other in time, according to the properties of the dependency between them. Those properties and their impact work as listed below:

  • Dependency type determines the direction of the dependency and also which of the Tasks' dates are relevant. We call them "relevant", because certain changes to those dates might cause either rescheduling of the dependant tasks or can be even impossible to perform (the app will immediately revert task to the previously calculated dates). To get more information on which are those changes and what is their outcome, see the table at the bottom of this page. Changes of the dates that are not "relevant" do not cause rescheduling of this dependency (but might still cause changes to its parent's or children's periods).
  • Lag Time is the time period calculated in days dividing the inked tasks. Lag time has the highest priority over other Dependency properties. In both ASAP and non-ASAP modes, the lag time will be respected and applied regardless of other circumstances. The type of Dependency determines which date (Start or End) of the Source task the Lag Time will be added to.
  • ASAP mode always schedules Target task to take place 'as soon as possible', according to dependency type. This renders the Target task strictly dependant on the Source. Therefore it will be impossible to drag and drop it, neither to the future nor the past. The Target task will always revert to its position previously calculated by scheduling.

Effort mode

The Resources and Gantt module show the resource workload vs capacity in three different effort mods:

  • Original Estimate Mode - use this mode to show planned workload versus the resource capacity.
  • Remaining estimate mode - use this mode to show workload history (Spent time), and the remaining workload versus the resource capacity.
  • Story points mode - use this mode to show the planned workload versus resource capacity expressed in Story Points.


Thanks to the Gadgets, you can add dynamic content to a Confluence page or the Jira application dashboard to monitor the health of projects, departments, or specific processes. This means that you can have your favorite Gantt charts and Risks all in one place and thanks to the auto-refresh all up to date.

There are three Gadgets available:

Holiday plans

A calendar that is used to reflect the non-working day which reduces the capacity of Teams or individual Resources (Team members).

Inheritance mode

When creating a new Box type or moving a sub-Box to a different parent Box, thanks to the Inheritance mode, the Box type configuration can be passed on from the upper-level Box type to the sub-Box type. 

There are three Inheritance modes that determine whether users will be able to customize the Box settings. Inheritance modes can be set for:

  • Card Views,
  • Quick filters
  • Column Views
  • Security


There may be a number of important dates that call for special care and attention. You can highlight them using a marker whatever they may be: from an important external event to a deadline, you name it. Once highlighted, they'll become instantly visible to all users with access to the App and appropriate security roles to view the Box content.

Markers can only be viewed using the App and when you add a marker, it will be visible on the timeline of the following modules:

  • Overview
  • Gantt
  • Board
  • Roadmap

With live synchronization and a variety of colors to choose from, you can make your timeline a complete source of information for everyone.


Any task can be converted into a milestone. On the timeline, milestones are represented as diamonds. The milestone duration is always one day.

Used to mark specific points along a project timeline and they do not impact the project duration. When a task is converted to a milestone, a label can be created #milestone in a filter to show milestones only.

Milestones can be interpreted as:

  • Markers of reaching an identifiable stage in any task or project.
  • Software release life cycle states.


You can select multiple tasks and perform bulk operations (deleting tasks, moving them to a different place in the hierarchy, outdent, indent, change task color).

Multi-select is supported by the following modules:

  • Overview
  • Gantt
  • Scope 
  • Board

Non-working days

The App can recognize non-working days and adjust the task period. This means that if you plan a task or part of your task's period on a non-working day it will be moved or extended or shortened.

You can define the non-working days in the Administration section:

Each non-working day reduces the capacity of your Resource. The capacity is calculated by the App and does not sync with the Host platform (you will not be able to see the capacity of your Resource directly in Jira or Trello).

Period warning

Period warnings occur when a parent task can't be recalculated due to a constrain, such as a blocking task (for example a task in Locked mode), non-working day, or when you use the manual period mode. 

The warning is displayed as a yellow box with a dashed-line frame and shows the position of the parent tasks calculated based on its children.

Task Progress

You can calculate the task progress using different fields and formulas. The progress can be displayed as a column, on the taskbar, and on the task details dialog once you click on the taskbar.

Resources panel

The Resources panel lets you see how much work has been assigned.

With the Resource panel enabled, the workload of each resource (assignee) will be counted in hours and color-coded depending on the resource capacity. 

The workload data is filter-sensitive, i.e. only the tasks in the current view are included in the workload calculation. You can use Quick filters or the Search Box to filter out tasks and simulate different scenarios.

As a rule, the effort is distributed evenly throughout the duration of a task but you can change how it is distributed in the Resources module. To learn more go to Workload contouring.


Any Jira issue with the "Risk probability" and "Risk consequence" fields values.

"Risk consequence" and "Risk probability" fields must be added to your Jira screen configuration scheme.

Risks module

The risks module consists of two main elements:

  • Customizable risk heat map
  • Customizable risk list (register)

You can configure a risk heat-map. The heat-map can be used to show the level of risk resulting from the risk assessment by considering the category of probability or likelihood against the category of consequences or severity.

You can define a name for the Risks axis and set corresponding custom in the Configuration of the App

Scenario mode

With the Scenarios feature you can easily try out different variants of your plan, compare the results, and find the best one.

All changes made to tasks are stored in the Scenario history, and you can easily undo them.  When you create a scenario, changes made to your tasks are synchronized with Jira or other connected tools, such as Trello, only after merging. 


A defined collection of tasks makes up the Box Scope. In general, tasks can be added to the scope manually or get automatically synchronized with Jira or connected tools such as Trello. 

In "Scope definition" you can specify what range of tasks is included in the scope of a given Box - those are the tasks you will be able to work within the Application (visualize them on a Gantt chart, manage Risks, distribute workload, etc). The App gives you a lot of flexibility; you can include multiple Jira projects, simultaneously include tasks from different external tools (such as both Trello and Jira), or include only some tasks that meet your particular specifications. The flexibility of the setup ensures you that a Box can be configured to contain exactly the tasks you need to fit your work.  

Scope type

The Scope type determines how the scope of the Box functions and how is related to and impacted by other Boxes.  

There are three different options:

  • Own-scope - the Box scope has a separate task structure and serves as a scope base for sub-scopes. Automatic rules can sync it. Use it when you want to be able to define and extend the scope of a Box by selecting tasks from Jira and connected tools. 
  • Sub-scope - the Box scope is always a subset of the scope already defined at an upper-level of the Box hierarchy. It can be automatically synced with a value of a selected field or manually adjusted using the Board module. 
  • None -  the Box scope cannot be defined. Currently, you can use such a Box for calculating respective aggregates in the Box hierarchy only (visible in the Overview module). Use this setting to organize Boxes into portfolios, programs, etc. The scope is always a sum of the scopes of the sub-Boxes in the Box hierarchy.

The Search box functionality will help you quickly find the things you're interested in, and filter out unwanted tasks or Boxes. The Search box operates in two modes:

    • Text search mode which filters information based on the Jira summary field (Boxes and tasks)
    • JQL mode which, as the name suggests, filters information using JQL queries (tasks only)

The Search box is available in the following modules:

  • Overview (text search only)
  • Gantt
  • Scope
  • Board
  • Risks
  • Calendar
  • Resources
  • Teams (text search only)

Snipe to task feature allows to quickly search and find task which fits search criteria.


 Information on Security settings can be found on the following pages:

  • Box Types - this page contains information on configuring the default Security settings that work as a template when you create new Boxes and the Inheritance mode.
  • Global Roles - this page explains App Administration settings and how access to the App is granted to, for example, Jira users.
  • Box configuration - this page explains what roles are available within the App and how to change them for an individual Box.
  • BigPicture configuration - this page gives you information on how to activate/deactivate the use of roles within the App.
  • Security - this page explains the impact of setting up security Roles for the Home (root) Box and lists available roles.

A short guide to security settings, access, and roles can be found here


The skills are defined at:

  • the task level - skill required to complete a task. The related effort is used to calculate the skill demand and it is evenly distributed over the task's duration. The skill demand will be display in the Resources module's Skill panel.
  • the resource level - skill acquired by the resource. The resource’s time is allocated across different skills. Skills weigh most in the "Perfect match algorithm" which is approximately 80%.

Each skill has a start and end date so you can plan the skill development over time.

Skills Panel

Skills Panel is a part of the Resources module. It displays a comprehensive list of skills required to complete tasks displayed on a timeline above. The time/story points are aggregated, so you can see exactly how much skill-related effort is needed to complete all the tasks planned for a particular period of time. 

You can change the view options to display additional information:

  • The unspecified - total effort of tasks for which the skill is not specified.
  • Skill Allocation - the total effort of tasks for which a given skill is set to 'required'. Only the tasks displayed on the Resource Grid (within the visualized period) are taken into account. For any task that is at least partly displayed, the skill effort is included in the calculation.
  • Skill Capacity - total skill capacity of the currently displayed resources.
  • Skill Remaining capacity - remaining availability in a given time period when a resource is assigned to a task.


Any Jira issue, Trello card, or Basic task (native to the App).  


Teams module lets you can group individual users into teams, which enables effort-based planning.

The concept of teams is used mainly in the ResourcesObjectives, and Board modules but, since the information about the team can be stored as a label or a custom field, it can be also displayed using Gantt, Scope, or Risks module by adding it to the Column View or to Card View.

You can create global teams and assign them to multiple Boxes. Once created, you can easily assign them to individual Boxes (a team is inherited and can't be edited on a Box level) or duplicate them in an individual Box (a team configuration is duplicated and can be further edited).

Team Capacity

The capability to achieve a set amount of productivity within a single day calculated as the sum of Team members' capacities. Team capacity factors in the existing manpower known to readily possess the necessary skill set as well as the number of hours in a workday.

Calculation of individual capacity takes into account team member's availability across all teams they're a part of.

Team code

Team code is used for identifying teams by the App's modules and, when synchronized, also the Host and connected platforms. Depending on the configuration, the Team code is stored as the following fields:

  • Labels type
  • Select list – single choice type
  • --none-- (not synchronized)

You can use these fields in your JQL to create a Jira Board dedicated to a specific team or as Quick Filters.

Team Member

A resource assigned to a team. 

Team Member Availability 

You can set availability for each team member (what percentage of their working hours is assigned to the team). Availability impacts the capacity - if a team has 4 members, and each is assigned 50% of their 8h day to the team, the team capacity for a day is 16h (if no other non-working days detract from capacity). 


Timeboxes define consecutive timeframes used for work planning. It helps to think of them as, e.g., sprints, iterations, increments, or stages.

Those Boxes don't have their own scope, they are used to organize and display tasks that have been added to the upper-level Box. The main Program/Project Box is where the tasks are added; then those tasks are assigned to various Timeboxes (for example, each Iteration could correspond to a sprint).

Timeboxes are sequential - their periods don't overlap.


The Timeline is a common element of the following modules:

  • Overview - Timeline mode - you can show and edit Boxes using drag and drop.
  • Gantt - you can show Tasks, Projects, Sprints, Backlog, Components, Versions, Boxes and Markers. 
  • Board and Roadmap - you can show Markers and Boxes. 
  • Resource - you can show tasks.


There are two widgets that you can add to the Detailed issue view:

Workload contouring (Box Configuration)

Workload distribution for a given task. Workload contouring allows you to specify how the effort of an assignee is distributed across a task period. 

Workload plan

A calendar that is used to reflect specific working hours of an individual resource and is the basis for capacity calculation of Teams or individual Resources (Team members). Workload plans are used for defining exact working hours. You can create as many as you like and assign them to your resources separately.