Content
 BigPicture

About BigPicture

BigPicture installation and updates

Quick start with BigPicture

BigPicture Sizing Guide

Cloud vs. Server - Key Differences in BigPicture on These Platforms

BigPicture Export

Progress Tracking

Tutorials and tips

Integrations

 BigPicture release notes

BigPicture Cloud Backlog

 BigGantt

About BigGantt

BigGantt - Important Notice

BigGantt installation and updates

BigGantt Cloud Backlog

Cloud vs. Server - Key Differences in BigPicture on These Platforms

 BigGantt release notes

Shortcuts
 Release notes
 BigPicture
 Jira Cloud

 Jira Server

 Trello

 BigGantt
 Jira Cloud

 Jira Server

 BigTemplate
 Jira Cloud

 Jira Server

 BigPicture Enterprise
 Jira Cloud

 Jira Server

Knowledge Base

Tutorials and tips

Search

Automated task structure

The task structure or hierarchy within a Program can be generated automatically by the app.  

You can set the suitable rules to structure your tasks by activating respective structure builders.

The order of structure builders will determine different levels of the hierarchy or in other words the first structure builder determine the highest level within the structure.

Remember that activating a structure builder (e.g. Project structure builder) without selecting a corresponding task type ("Synchronize JIRA projects" in this case) is insufficient.

You need to select e.g. "Synchronize JIRA projects" in the Task type section to allow the app to add a proper task to the scope of the Program which is required to build the structure.

Please note that the order of the active structure builders is important for the final result of the automatically built structure.

Below are some main bullet points worth remembering when using the structure builders:

  • once the structure builders are defined and the tasks loaded in the program the structure is preserved by the plugin until a change is forced to rebuild the program,
  • rearranging the structure builders does not mean that the remembered WBS structure is reorganized,
  • tasks already in the program may have different parents than those newly added (even though they have same potential parents like links or projects) as it depends on the structure builders' settings at the moment of adding the tasks,
  • tasks newly added to the program follow the rules currently defined in the structure builders' settings,
  • it is important to pay attention to inverse option while using the 'Link based' structure builders to get the parent child relations represented correctly on the Gantt chart,
  • the "Relates to" Link structure builder may be misleading as it is difficult to see the difference between inward and outward links,
  • resetting the WBS structure clears the WBS structure (with all the manual and auto changes) remembered by the plugin (flattening it effectively) and forces reapplying the rules as defined anew.

Structure builders - basic rules

The order of the active structure builders specifies:

  1. the sequence of the performed executed "parent finding" loops executed by the app for every task in the scope of the Program:
    1. e.g: try to find Project parent task → then try to find Version parent task → then try to find Epic parent task etc.
  2. the business priority of the structure builders:
    1. eg. if the order of the structure builders is as follows: Project → Version → Epic, a app assumes that a Version based structure is more important than an Epic based structure.

Resetting the structure

To flatter the task structure disable all of the structure builders and check the reset option at the bottom of the list.

Automated structure building - how does the algorithm work?


When a full-sync is executed, the following steps regarding structure building are performed:

  1. The app adds all additional tasks (all tasks which are not Jira issues, but they are included in the scope based on selected Task types in Synchronization tab: Projects, Components, Versions, Agile Backlogs, Agile Sprints) to have all tasks in the scope (and as a consequence: all potential parent tasks in the scope).
  2. A app executes two following loops to build a proper task structure: 
    1. a loop for all active structure builders,
    2. a loop for all tasks in the scope.
  3. It means that: 
    1. At first, the app tries to find a parent task for every task consecutively based on the first active structure builder,
    2. Then it tries to find a parent task again for every task consecutively based on the second active structure builders etc. until all active structure builders are verified.
  4. The following rules are applied by finding a parent task for a given task within a consecutive structure builder: 
    1. the app always respects an already built structure by indenting a task (if an indent of the task would be contradictory to its current parent tasks, then an indent is not executed so that a structure builder never overwrites the current task structure)
    2. an indented task is always moved with all its child tasks.
Please note, that the final result of the automatically built task structure based on the active structure builders can be different depending on the structure at the moment of the full-sync.

If you want to reorganize your task structure entirely after it was already built, follow the steps:

  1. switch of all structure builders,
  2. select "reset Work Breakdown Structure" option,
  3. click on "Save and sync".

After taking those steps, your scope will be flattened. Activate the new structure builders to build a respective task hierarchy again.


Illustrative example

The input data is presented in the tabel below:

#1 Tasks in the scope:

Task

Jira project

Fix Versions

Epic link

Project Ana.na.na.
Version 1.0Ana.na.
Version 2.0Ana.na.
Epic-1A-na.
Epic-2A1.0na.
Story-1A1.0Epic-1
Story-2A-Epic-1
Story-3A-Epic-2
Story-4A1.0Epic-2
Story-5A2.0Epic-2

#2 Active structure builders:

  1. Project
  2. Version
  3. Epic

#3 The list of the tasks at the beginning of the WBS building is flat (no parent tasks).

Output data (automatically built structure):

1st level

2nd level

3rd level

4th level

Explanation of the task position in a structure

Project A


the task does not have a parent resulting from active structure builders


Version 1.0

the parent is Project A, as:

  • "Project structure builder" condition is met


Epic-2

the parent is Version 1.0, as:

  • "Project structure builder" condition is met
  • "Version structure builder" condition is met



Story-3

The parent is Epic-2, as:

  • "Project structure builder" condition is met
  • "Epic structure builder" condition is met
  • "Version structure builder" condition is not applicable (Epic1 does not have a version specified)



Story-4

The parent is Epic-2, as:

  • "Project structure builder" condition is met
  • "Epic structure builder" condition is met
  • "Version structure builder" condition is met


Story-1


The parent is Version 1.0, as:

  • "Project structure builder" condition is met
  • "Version structure builder" condition is met
  • "Epic structure builder" condition is ignored ie. version structure builder has a higher priority and Epic builder would cause a conflict (Epic-1 is not included in Version 1.0)

Version 2.0

The parent is Project A, as:

  • "Project structure builder" condition is met


Story-5

The parent is Version 2.0, as:

  • "Project structure builder" condition is met
  • "Version structure builder" condition is met
  • "Epic structure builder" condition is ignored ie. version structure builder has a higher priority and Epic builder would cause a conflict (Epic-1 is not included in Version 2.0)

Epic-1

The parent is Project A, as:

  • "Project structure builder" condition is met
  • "Version structure builder" condition is not applicable (Epic-1 does not have any version specified)


Story-2


The parent is Project A, as:

  • "Project structure builder" condition is met
  • "Version structure builder" condition is not applicable (Epic-1 does not have any version specified)
  • "Epic structure builder" condition is met