Contents:
|
|---|
...
The article below refers to a situation when a task has been being added to a single "Own scope" Box.
For example, the following situation:
The main Program-type Box has its "own" scope (tasks are added to the 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
To find out Check the Task Dates page to learn more about tasks without start/end dates, click here.
Start/end date overwritten
...
| Info |
|---|
The scheduling mode of a task is the strictest scheduling rule, but it relies on parent-child relationships within the task tree. It is necessary to understand Understanding the automatic rules that impact WBS is necessary to understand comprehend scheduling outcomes. |
General priority of scheduling rules:
...
A newly created task changes based on other tasks , but it can also force other existing tasks to change. The impact is presented in the following table:
New task | Impacted by | Impacts |
|---|---|---|
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) |
scheduling mode | "auto top-down" parent impacts:
| all tasks impact an "auto bottom-up" parent |
...
Mechanisms dependent on task field values | Result | 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: 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 boxes based on a field value. This can change the task period if task period alignment rules are active for a given Box (main Program-type Box, Iteration, Program increment, etc.) | Relevant only if combined with Task period alignment rules. Otherwise, it has no impact on task scheduling. Box: Auto-assignment rules can be created only when "sub-scope" sub-Boxes boxes exist Task: A 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-Boxesboxes, but the "sprint" field it 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:
| 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-type Box and its sub-Boxes. You can "set assignment on lower levels" directly from the main Program-type Box. |
Dependencies | During task creation, you can add dependencies. Scheduling rules resulting from those dependencies apply to a newly created task. Keep in mind , that links between tasks can function as:
This means that adding Adding a link can move the task within the WBS structure and /or move the task on the timeline. | Applies This applies only if task links have been added. |
Independent from task fields | ||
Scheduling mode | Scheduling mode of newly created tasks is based on Box Configuration > Tasks > Scheduling settings. | Always applies. Box: Task: |
...
Task position in the tree structure will affect affects what scheduling rules apply.
Position in the tree is vital, as it determines what task is in the role of a 'parent' and 'child.' Tree relationships determine how the scheduling mode rules are executed.
Task place in WBS is affected by:
...
| Info |
|---|
A task can be moved after it was created, but:
Therefore, it is crucial to create creating a task in the correct place in the WBS is crucial. |
| Expand | ||
|---|---|---|
| ||
A task can be moved using the Indent/outdent/move up/ move down button OR using the drag-and-drop method.     |
| Anchor | ||||
|---|---|---|---|---|
|
...
| Warning |
|---|
When no task is selected, the App will create creates 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 is positioned at the least indented level possible and placed at the bottom of the list.
Task position in WBS will depend depends on the structure builder settings of a Box.
...
In the sections below, you can find an explanation description of function of what each scheduling rule is trying to accomplish.
Scheduling 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 scheduling mode of newly created tasks?
...
other "auto top-down" tasks
"auto bottom-up" tasks.
During task creation:
Situation | Outcome |
|---|---|
New task fits within the parent task period | no changes made to the period of the new task |
New task partially fits within the parent task period | task 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 top-down" tasks
"auto bottom-up" tasks.
During task creation:
Situation | Outcome |
|---|---|
New task fits within the parent task period | no changes made to the period of the new task |
New task partially fits within the parent task period | task 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 |
...
Dependency | Result |
|---|---|
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 the Box it's in.
Task period alignment | Results |
|---|---|
no alignment | task period = unaffected |
precise alignment | Task period = Box period |
smart adjustment | Task's time frame aligns with the start and/or end date of a Box. Task's length remains unchanged (whenever possible) |
...
Scheduling mode is executed:
auto top-down parent = child adjusted to fit
auto bottom-up parent = parent changed based on the child.
Dependencies are executed:
task moved according to a dependency
if the "auto bottom-up" parent period has been changed during the scheduling 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).
Scheduling mode vs. task period alignment
...
Task period alignment is executed.
Scheduling mode is executed - it overwrites the previous changes if necessary.
Dependency vs. task period alignment
...
Task period alignment is executed.
Scheduling mode is executed.
Dependency is executed.