The article below refers to a situation when a task has been added to a single "Own scope" Box. 

For example, the following situation:

  • Main program Box has its "own" scope (tasks are added to scope definition of the Box)
  • The project Box can be further divided ( for example, into Program Increments and Iterations)
  • If Program Increments and Iterations are set up to function as "sub-scope" Boxes = their scope is based on the main Box

In the example below, a task can be in the OMEGA Box (own scope) + Program Increment 1 (sub-scope Box) + Iteration 2 (sub-scope Box)
 

Start/end date not specified

When you create a task and don't specify start/end dates:

  • task duration = 1d
  • task start/end date = creation date (unless other scheduling rules apply)

Start/end date overwritten

Based on scheduling rules, the App can make changes to:

  • task duration
  • task placement on the timeline

Priority of scheduling rules

The period mode of a task is the strongest scheduling rule, but it relies on parent-child relationships within the task tree.

To understand scheduling outcomes it is necessary to understand the automatic rules that impact WBS.

General priority of scheduling rules:

  1. Period mode
  2. Dependencies
  3. Task period alignment

In reality, when you create a new task:

  1. WBS is determined by:
    1. Structure builders
      1. structure builders can be based on dependencies
    2. Manual task placement (adding a task in a particular spot in the task structure)
  2. Task period alignment applies
    1. rules of the "own scope" Box
    2. rules of the "sub-scope"Box → auto-assignment (sync with a selected field) 
  3. Period mode rules apply (based on WBS)
    1. auto top-down > auto bottom-up
  4. Dependencies apply
    1. Strong dependencies dictate the placement of start/end dates
    2. Period mode rules are prioritized. Dependency will still exist, but the outcome will be limited by period mode

A newly created task changes based on other tasks, but it can also force other existing tasks to change.

New task impacted byimpacts
dependencies

a task can be a target of a dependency (it is affected by the source task)

a task can be a source of a dependency (it affects other tasks) 

period mode

"auto top-down" parent impacts:

  • "auto top-down" children
  • "auto bottom-up" children
all tasks impact an "auto bottom-up" parent

Task creation (field values) - scheduling mechanisms involved in task period calculation

The fields you fill in when adding a task determine what scheduling mechanisms apply and how they will position a task.

Depending on:

  • the setup of a Box
  • task fields filled in
mechanisms dependent on task field valuesresult

applicability

Structure Builders

Automatic WBS structure is based on Box Configuration > Tasks > Task structure.

Structure builder rules can be manually broken. This means, that when you create a new task it is placed according to Structure Builders, but afterward, you can move it.

If structure builders don't apply, tasks will be created exactly where you have manually specified.

Applies only if structure builders are active AND task is affected by them.

Box:
Structure builders can be deactivated for a given Box

Task: 
A task may remain unaffected if existing rules can't be applied to it (for example, "epic link" is used as one of the structure builders, but an epic link hasn't been defined for a task.)

 


sub-Box auto-assignment

(relevant to scheduling only if combined with Task period alignment)

Sub-Boxes (such as Iterations and Program Increments) can be synced with a selected field. This means that tasks can be automatically assigned to sub-Boxes based on a value of a field. 

This can change the task period if task period alignment rules are active for a given Box (main program Box, Iteration, Program increment etc.)

Relevant only if combined with Task period alignment rules. Otherwise, has no impact on task scheduling. 

Box:

Auto-assignment rules can be created only when "sub-scope" sub-Boxes exist

Task:

Task may remain unaffected if existing rules can't be applied to it (for example, the "sprint" field is used to sync tasks with Iteration sub-Boxes, but the "sprint" field hasn't been filled in for a given task).

Task period alignment

While task period alignment isn't directly related to any field, depending on the scope definition rules:

  • adding a field value can automatically assign a task to a sub-Box
  • which will make task period alignment rules of that Box apply to a task

Applies if task period alignment is active. 

Task period alignment rules are set up per Box (Box Configuration > Tasks > Scheduling). Check the settings of your main program Box and its sub-Boxes.

You can "set assignment on lower levels" directly from the main program Box. 

Dependencies

During task creation, you can add dependencies. Scheduling rules resulting from those dependencies apply to a newly created task. 

Keep in mind, links between tasks can function as:

  • strong dependencies
  • soft dependencies (no scheduling impact)
  • structure builders

This means that adding a link can both move the task within the WBS structure and/or move the task on the timeline. 

Applies only if task links have been added. 


independent from task fields

Period modePeriod mode of newly created tasks is based on Box Configuration > Tasks > Scheduling settings. 

Always applies.

Box: 
Period mode of newly created task is always based on Box settings.

Task: 
A task must alway be in one of four available period modes.


Position in WBS

Task position in the tree structure will affect what scheduling rules apply. 

Position in the tree is key, as it determines what task is in a role of a 'parent' and 'child'. Tree relationships determine how the period mode rules are executed. 

Task place in WBS is affected by:


A task can be moved after it was created, but:

  • the rules resulting from the initial placement have already been applied (various task periods have been adjusted accordingly)
  • moving a task will trigger period recalculation to validate rules resulting from the new position (task period will be changed if needed), but changes to other tasks won't necessairly be automatically reverted. 

Therefore, it is crucial to create a task in the correct place in the WBS.

 Moving a task

A task can be moved using the Indent/outdent/move up/ move down button OR using the drag-and-drop method



Structure Builders

Example:

"Epic link" is listed as a structure builder:

The task is created directly in Jira. "Epic link" field has been filled in:

The task is nested according to structure builder settings of a Box:

Even when you try to create a task in a particular spot in the structure, it will be moved according to existing structure builders: 


Changing an existing task can result in a task being moved based on structure builders:



Structure builder rules can be manually broken. This means, that when you create a new task it is placed according to Structure Builders, but afterward, you can move it manually within the structure.

Inline task creation

Two key things to keep in mind:

  • Between what tasks are you adding a task
  • Is the structure expanded

Between same level tasks

When you create a task between the same level tasks (collapsed structure = two tasks on the same level) you will create a same-level task:

Task added:

Between different level tasks

When the task structure is expanded, the"add task" inline button can be positioned between different level tasks. The resulting task is always created at the more indented level (nested lower in the structure):

Task added:

Additional example:


Add task button

Click on a task to select it (it will be highlighted in blue). A same-level task will be created when you use the "Add task" button, regardless of whether the tree is expanded.

When no task is selected, the app will create a new task under the last task that has been selected. Even if nothing is selected at the moment! Always remember to select a parent task when using this task creation method. 


Resulting task

Directly in Jira

When you create a task directly in Jira, it will be positioned at the least indented level possible and placed at the bottom of the list.

Task position in WBS will depend on the structure builder settings of a Box. 

Scheduling mechanisms

In the sections below, you can find an explanation of what each scheduling rule is trying to accomplish.

Period mode

Tasks can be in one of four modes:

  • Locked = task duration can't be changed (task unaffected by other scheduling rules; task limits period of children)
  • Manual = task duration has to be changed manually (task unaffected by other scheduling rules)
  • Auto top-down = task has to fit within the period of its parent 
  • Auto bottom-up = task period changes the period of its parent

What is the period mode of newly created tasks?

Box settings determine the period mode of newly created tasks.

The "auto top-down" tasks have priority over "auto bottom-up" tasks.

  • parent affects child
  • parent is affected by child
child
lockedmanualauto top-downauto bottom-up

parent 

lockedN/AN/AAFFECTSAFFECTS
manualN/AN/AN/AN/A
auto top-down

N/A

N/A

AFFECTSAFFECTS
auto bottom-upAFFECTED BYAFFECTED BYAFFECTED BYAFFECTED BY

Summary:

  • "auto bottom-up" parent = affected by period of any child task
  • "locked" parent = restricts period of "auto top-down" and "auto bottom-up" tasks
  • "auto top-down" parent = restricts period of "auto top-down" tasks and "auto bottom-up" tasks

"Auto top-down" parent task

An "auto top-down" parent task forces a child to fit within its period. 

Affected tasks:

  • other "auto top-down" tasks
  • "auto bottom-up" tasks

During task creation:

situationoutcome
New task fits within the parent task periodno changes made to period of the new task
New task partially fits within the parent task periodtask duration shortened - days outside of the parent task period are 'cut off'
New task has no overlap with the parent task period

task duration = 1d

task placed on a timeline closer to the start/end dates specified during task creation

"Locked" parent task

A "locked" parent task forces a child to fit within its period. 

Affected tasks:

  • "auto top-down" tasks
  • "auto bottom-up" tasks

During task creation:

situationoutcome
New task fits within the parent task periodno changes made to period of the new task
New task partially fits within the parent task periodtask duration shortened - days outside of the parent task period are 'cut off'
New task has no overlap with the parent task period

task duration = 1d

task placed on a timeline closer to the start/end dates specified during task creation

"Auto bottom-up" parent task

An "auto bottom-up" parent task is affected by the period of any child (regardless of their period mode).

Dependencies

Strong dependencies move a task on a timeline.

Without the involvement of another mechanism, dependencies don't alter task period.

Dependencies have a lower scheduling priority than period mode.

The source of a dependency remains in its original position - target of a dependency is moved.

dependencyresult
end to start

end to end

start to end

start to start

Task period alignment

Task period alignment settings of a box regulate the relationship between a task and a Box it's in. 

task period alignmentresults
no alignmenttask period = unaffected
precise alignmentTask period = Box period
smart adjustmentTask's time frame aligns with the start and/or end date of a Box. Task's length remains unchanged (whenever possible)

Task period alignment won't be realized if it's in conflict with parent task period mode requirements. 

Conflicts

Starting state to which scheduling mechanisms are applied:

start/end date unspecified during task creationstart/end date specified during task creation

New task:

  • duration = 1d
  • start/end date = creation date

New task:

  • duration = based on start/end date
  • start/end date = as specified during creation

Period mode vs dependency

Order of execution:

  1. Period mode is executed
    1. auto top-down parent = child adjusted to fit
    2. auto bottom-up parent = parent changed based on the child
  2. Dependencies are executed
    1. task moved according to a dependency
    2. if the "auto bottom-up" parent period has been changed during the period mode execution, it won't be further changed (for example, if the parent has been lengthened to encompass the new child, it won't 'shrink' back down, even if it would be possible after dependency moved the task)

Period mode vs task period alignment

Order of execution:

  1. Task period alignment is executed
  2. Period mode is executed - it overwrites the previous changes if necessary

Dependency vs task period alignment

Order of execution:

  1. Task period alignment is executed
  2. Task is moved according to the dependency

This means that based on task period alignment, a task can be shortened/extended and then moved on a timeline. Since dependencies themself don't modify task period, task duration will be determined by task period alignment, but the position will be based on strong dependencies.

Dependency vs task period alignment vs period mode

Order of execution:

  1. Task period alignment is executed
  2. Period mode is executed
  3. Dependency is executed