Scheduling mode (previously period mode)
Introduction
The scheduling mode determines whether a task is scheduled manually or automatically, which gives you the option of deciding how much control you want over task scheduling in a Box.
The default scheduling mode depends on box configuration settings. To learn more about the scheduling rules, see the Automation (auto-scheduling) page.
There are four different modes explained further below:
Auto bottom-up
Auto top-down
Manual
Locked
The 'Auto bottom-up' scheduling mode is applied to tasks with empty date fields to avoid data corruption when the tasks are structured automatically using presets.
Configuration
The App admins can set the default mode of a box type in BigPicture Administration.
The Box admins can change the default scheduling mode of a box in the box configuration.
To enable the task scheduling:
Go to App configuration (wrench icon at top right) > BigPicture configuration > General > Fields. Only Jira administrators can access this page. The App creates a select list (single choice) custom field 'Task modes' during the installation.
Set the task scheduling mode
Inline editing
You can use inline editing to change the scheduling mode of a task:
Gantt
Scope
Board
Risks
Keep in mind, a change of a task scheduling mode can have a significant scheduling impact. If needed, switch to a different module to assess the situation before making a change.
Gantt module
In the Gantt module, there are multiple ways of changing a scheduling mode.
You can change the scheduling mode of a single task (or a group of tasks, using the multi-select option) by using the right-click dialog:
You can also select multiple tasks and click on the three-dot menu in the middle:
Available scheduling modes
Auto basic mode
Auto basic mode is the default scheduling mode in BigPicture.
Tasks in Auto basic mode react to automation based on non-working days, dependencies, and parents in Auto top-down and Locked mode.
Tasks set to Auto basic mode do NOT affect children’s dates (as tasks in Auto bottom-up mode) and do NOT shift children’s tasks when tasks are moved.
Manual
The start/end dates of a task have to be manually changed.
Start/end dates are unaffected by:
Dependencies
Scheduling mode of other tasks (an "auto top-down" parent task won't reposition a "locked" child)
A move of a parent task on a timeline
When in 'Manual' mode, you can enable the period warnings to show how your tasks impact other tasks in the task structure.
Locked mode
The duration and position of Locked tasks can't be changed.
Start/end dates are unaffected by:
Manual changes of start/end
Dependencies
Scheduling mode of other tasks (an "auto top-down" parent task won't reposition a "locked" child)
A move of a parent task on a timeline
To change the start/end dates of a "locked" task, you have to change the scheduling mode first.
Auto top-down mode
Child position - affected
A parent task in an "auto top-down" mode repositions its children ("auto top-down" and "auto bottom-up") to fit within its period:
When a child is longer than the parent, start dates are matched (child duration is NOT changed):
Child duration (period warning)
An "auto top-down" parent doesn't change the duration of a child.
When period warnings are active, the discrepancy of task periods is indicated:
Auto bottom-up mode
An "auto bottom-up" task period changes based on its children's period, i.e.:
Start date of the "auto bottom-up" task = earliest start dates of the child tasks
End date of the "auto bottom-up" = latest end date of child tasks
General rules and outcomes
The general rules and outcomes are presented in the table below:
Scheduling mode | Task impacted by other tasks or dependencies? | Task impacted by non-working days? | Does moving the task affect children? | Task start/end date editable /movable? |
---|---|---|---|---|
Auto basic | Yes | Yes | No | Yes |
Locked | No | No | Yes | No |
Manual | No | No | Yes | Yes |
Auto top-down | Yes, by either
| Yes | Yes | Yes |
Auto bottom-up
| Yes, by either
| Yes | Yes | Yes |
Scheduling mode of new tasks
When you add a new task in a Box, the default scheduling mode of that Box applies.
When you add a new task directly to the task source (for example, to a Jira project), the default scheduling mode is selected automatically.
For this, the App considers the default scheduling modes of all Boxes that the task falls into and then selects the dominant one, following the prioritization below:
Locked,
Auto bottom-up
Auto top-down
Manual
Locked
Default scheduling mode for extra tasks
You can configure the default scheduling mode for each task type, including extra tasks such as Jira epics, components, projects, sprints, versions, etc. This way, new task types you add to a box in the future will get the default scheduling mode. The configuration works per box or box type.
Edit the default scheduling mode
To edit the default scheduling mode for Jira components, projects, sprints, and versions:
Go to Box configuration > Tasks > Scheduling.
Expand the Advanced configuration tab.
Click Edit next to the task type.
Select the scheduling mode.
Click Edit to save.
The video presents how to edit the default scheduling mode for Jira components.
Add the default scheduling mode for new task types
To add the default scheduling mode for a new task type:
Click Add task type.
Select a task type.
Select the scheduling mode.
Click Add to save.
The video presents how to add a new task type and set the default scheduling mode.
Delete the default scheduling mode for task types
To remove a task type and its default scheduling mode:
Find a task type.
Click Delete next to the task type.
Click Delete to confirm.
Limitations
Tasks based on Jira sprints
A sprint task cannot have a scheduling mode set to auto bottom-up.
Period mode vs strong dependencies
Strong dependencies do NOT affect auto bottom-up tasks (if the child tasks conflict with the change).
An auto bottom-up task can have children nested underneath it in the tree structure. In this situation task period is limited by the periods of its children (won't be affected by a strong dependency, if there is a conflict):
Possible changes to make a strong dependency affect the tasks:
Changing the scheduling mode of the parent to top-down:
Drawing the Strong dependency to a child under the auto bottom-up parent (moving the child will expand the parent, but not move it).
Before:
After: