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 in Program Box Configuration - Tasks - Scope definition - Automatic rules is insufficient.
If you want to structure your task automatically make sure that the correct structure builders are enabled and required task types selected.
For example, to create a simple structure based on Projects - select the Project task type in the Automatic rules section and enable the Project structure builder.
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 structure,
- rearranging the structure builders does not mean that the remembered task 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 task structure,
- the "Relates to" Link structure builder may be misleading as it is difficult to see the difference between inward and outward links,
- resetting the task structure clears the 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:
- the sequence of the performed executed "parent finding" loops executed by the app for every task in the scope of the Program:
- e.g: try to find Project parent task → then try to find Version parent task → then try to find Epic parent task etc.
- the business priority of the structure builders:
- 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:
- 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).
- A app executes two following loops to build a proper task structure:
- a loop for all active structure builders,
- a loop for all tasks in the scope.
- It means that:
- At first, the app tries to find a parent task for every task consecutively based on the first active structure builder,
- 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.
- The following rules are applied by finding a parent task for a given task within a consecutive structure builder:
- 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)
- an indented task is always moved with all its child tasks.
If you want to reorganise your task structure entirely after it was already built, follow the steps:
- switch of all structure builders,
- select "reset Work Breakdown Structure" option,
- 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 A | na. | na. | na. |
Version 1.0 | A | na. | na. |
Version 2.0 | A | na. | na. |
Epic-1 | A | - | na. |
Epic-2 | A | 1.0 | na. |
Story-1 | A | 1.0 | Epic-1 |
Story-2 | A | - | Epic-1 |
Story-3 | A | - | Epic-2 |
Story-4 | A | 1.0 | Epic-2 |
Story-5 | A | 2.0 | Epic-2 |
#2 Active structure builders:
- Project
- Version
- 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:
| |||
Epic-2 | the parent is Version 1.0, as:
| |||
Story-3 | The parent is Epic-2, as:
| |||
Story-4 | The parent is Epic-2, as:
| |||
Story-1 | The parent is Version 1.0, as:
| |||
Version 2.0 | The parent is Project A, as:
| |||
Story-5 | The parent is Version 2.0, as:
| |||
Epic-1 | The parent is Project A, as:
| |||
Story-2 | The parent is Project A, as:
|