Scheduling behavior
The automatic scheduling mechanism in Portfolio for Jira is one of its core capabilities, and it provides a better way for you to optimize and allocate resources realistically.
A plan schedule in Portfolio for Jira may display work items in either dark blue or light blue background:
- Dark blue work items are estimated, and are thus scheduled by the automatic scheduling mechanism in Portfolio for Jira
- Light blue work items are unestimated, but are scheduled because these have either a sprint, a release, or targets dates assigned to them
- Light blue bars on work items indicate dependencies between work items in the backlog:
if the light blue bar is at the beginning of an issue, that issue is dependent on another issue
- if the light blue bar is at the end of an issue, that issue is a dependency for another issue
For unestimated light blue work items that have been scheduled...
- If the plan is using a project or JQL as an issue source, sprint data will not be added to the plan.
- If the plan is using a Scrum board as an issue source, sprint data will be added to the plan if the board is assigned to the team in the plan.
For more information on how unestimated items are scheduled in Portfolio for Jira, see Scheduling unestimated items.
Portfolio for Jira uses the following factors to create a sensible schedule of your team's work items:
- Estimates, and required skills and capacity
- Team schedules, e.g. working in either sprint iterations, or in a continuous flow of daily tasks
- Work stages, e.g. whether activities can happen either in parallel or in a specific sequence in the plan
- The sequence of work items, based on start and end release dates
- The ranking of work items in the backlog
- Dependencies between work items in the backlog
- Configurable constraints, e.g. how many people can work in parallel on a story
- The skills of each team member
- Availability of teams and people, taking into account holidays
Portfolio for Jira also shows you some of the factors that were considered when work items are scheduled off the backlog, as well as gives you an idea why some work items weren't scheduled as such as well.
You can find these details for each issue in the 'Scheduling factors' section of the Scope view.
The sample screenshot shows the factors behind how issue XPLN-38 is scheduled in the timeline:
- XPLN-38 is assigned to release 1.5.0.
- XPLN-38 is ranked at position 2 in the scope backlog.
If you want to know how to move this work item either earlier or later in the schedule, click earlier or later correspondingly.
Assigning automatic releases
Releases are automatically assigned only if there is at least one release that has a fixed end date. In this case, if you have backlog items that have their release assignment set to Calculate, these items will be automatically assigned to the release with a fixed end date. This is automatically based on how the items are ranked in the backlog.
Portfolio for Jira optimizes the scheduling of work items that are ranked the highest. This means that even if your team has more capacity for v2.0 release, if the items set for v2.0 are ranked low in the backlog, Portfolio for Jira will still plot these items for v2.0 later on in the schedule.
If you want items of the highest risk to be worked on earlier in the schedule, you may want to give these items a higher ranking. Your team can then tackle these items much earlier.
Scheduling automatic and manual assignments
Portfolio for Jira lets you decide how the scheduling algorithm sets values to certain fields – whether these values are assigned manually (static assignments) or suggested automatically (calculated assignments).
| Field | Manual assignments | Automatic assignments |
|---|---|---|
| Release | You determine into which release a work item should be shipped in. "Item should be shipped with release X." | The scheduling algorithm determines into which release a work item fits. "Into which release does the item fit?" |
| Team | You make the call which team will implement a work item. "This story should be implemented by team A." | The scheduling algorithm determines which team can best deliver the work item, based on skills and capacity. "Based on skills and capacity, which team can deliver this best?" |
| Members | You decide which team members will handle a work item. "Peter and/or Sarah should work on this story." | The scheduling algorithm determines which team members can best handle a work item, based on skills and availability. "Based on their skills and availability, which team members can best work on this story?" |
| Sprints | You decide into which sprint the work item will be worked on. "Item should be worked on in sprint 3." | The scheduling algorihtm determines into which sprint the work item will be worked on, based on availability. "Into which sprint does the item fit?" |
Note that if you set a field to calculate from the drop-down menu, a value is then automatically assigned upon the next calculation, and the field will be highlighted in blue.
Planning work over a period
Portfolio for Jira has a planning horizon of 5 years by default. If you believe that your schedule isn't being displayed properly, and your estimates are for less than 5 years, please check your team's capabilities and estimates. If you require a longer planning horizon, up to 30 years, please contact Atlassian Support.