Auto-scheduling issues

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

Before you start auto-scheduling work for your teams, it's important to note that the auto-scheduling functionality technically replaces the previous calculating functionality in live plans.

As such, these are the following differences between the previous and the current functionality:

Technical detailsLive plansPlans with the improved interface
Scheduling unestimated issues

If an unestimated issue is assigned to a release, the scheduler will use the dates of this release to schedule the issue by default.

You can configure how to schedule unestimated issues in a live plan.

By default, the scheduler uses target dates to schedule unestimated issues, and the issues will be scheduled to last the duration of their target dates. You can choose to use custom dates instead of target dates. See Scheduling to learn more.

For unestimated issues that are assigned to any sprint, release, or team, the values for these will persist regardless of the auto-scheduled settings that you've configured.

Sprints, teams, and releasesThese can be ignored for explicitly marked issues.These can be ignored, depending on how auto-scheduling settings are configured.
Maximum people assigned per storyYou can configure how many people can be assigned to a story.Only one (1) person can be assigned to a story.
Plan time zoneDepends on how it's configured in the plan. The available options include plan time zone, system time zone, or coordinated universal time (UTC).UTC is always used in the improved interface.
Earliest start date, resource assignments, stages, and skillsAll of these are taken into account when issues are calculated.

These details are no longer available in the improved interface, and have no impact when issues are auto-scheduled.

Resource join date, leave dates, and availabilitiesAll of these are taken into account when issues are calculated.These details are no longer available in the improved interface, and have no impact when issues are auto-scheduled.
Auto-scheduling of programsThe calculation of each plan aggregates into the program level.The program's schedule is derived from the dates, sprints, and releases of each plan in the program.

Auto-scheduling in the improved interface

In the improved interface, you can choose to:

  • manually schedule work, by dragging and dropping schedule bars in the timeline
  • automatically schedule work, by letting Portfolio for Jira schedule your work automatically, based on known issue details. The auto-scheduled changes will be displayed in purple stripes as a preview. You can choose whether or not to accept these changes — and if accepted, the changes will then be implemented in your plan.

When auto-scheduling the issues in a plan, Portfolio for Jira considers several factors to come up with the ideal schedule for your teams:

  • how your teams work, i.e. in sprint iterations (Scrum), or in a continuous flow of daily tasks (Kanban)
  • for Scrum teams, the sprint assignments of the issues in the plan
  • the sequence of issues, based on start and end release dates
  • the ranking of the issues in the plan
  • the dependencies between issues in the plan
  • the estimates of the issues in the plan
  • the number of members in your team, which determines how much work can be completed in parallel

Sample plan with issues not yet auto-scheduled

Configuring the auto-scheduling settings

You can further configure the auto-scheduling settings, by choosing:

  • which fields (from sprints, releases, and teams) can be overwritten with auto-scheduled values,
  • and how these fields will be overwritten with the auto-scheduled values, i.e. only empty fields or all fields will be overwritten.

Sample auto-schedule settings

In the example above, when you're auto-scheduling your plan, you're allowing the auto-scheduler to overwrite the values for the sprints and releases of the issues all the time. However, the auto-scheduler can overwrite team values only for issues that have no teams specified for them. Once you've configured your auto-schedule settings, you can then preview the changes being suggested by clicking Preview results.

Note that if an issue is unestimated, and it's currently assigned to a sprint, release, or team, these values will not be overwritten, even if you choose to overwrite all issue values for your auto-schedule settings.

Auto-scheduling a plan

When you're auto-scheduling a plan, the issues in the plan are being auto-scheduled based on the plan permissions that you have. See Permissions in Portfolio for Jira for more details.

  1. Above the timeline section of your plan, click Auto-schedule.

  2. Configure the auto-schedule settings as needed.
  3. Click Preview results. This will display a preview of the auto-scheduled changes that Portfolio for Jira is suggesting for your plan.

    Sample plan with auto-scheduled issues being displayed in a preview

    The number of auto-scheduled issues will depend on the hierarchy levels you've chosen for the plan. Also, note that in the timeline section, the schedule bars of the auto-scheduled items will appear in purple stripes. Similarly, in the fields section, the corresponding issue details will also appear in purple stripes, of a lighter shade.

  4. Review the auto-scheduled changes more closely by hovering on each change, to see the current value saved in the plan, and the new value that will be saved in both the plan and Jira, if the changes are accepted.

    Comparing current values and new values

    In the example above, three (3) values will be auto-scheduled for the issue — target start daterelease, and sprint. If you accept the changes, the new values will be updated in your plan.
  5. Perform one of the following actions:
    • To save the changes in your plan, click Accept changes. Note that these changes are just saved in your plan, and are not yet saved in Jira. See Saving changes in Jira to know more.
    • To discard the changes, click Cancel. The changes will not be saved in the plan, nor saved in Jira.
  • While Portfolio for Jira is auto-scheduling the issues in a plan, you won't be able to review any changes that have already been made.
  • You also cannot review changes when you're previewing the results of auto-scheduling until you either accept or cancel the suggested changes.
  • If you've chosen to overwrite any values for sprints, releases, or teams, these values will be overwritten except for issues that are in a currently active sprint.

Notes when auto-scheduling issues

Jump to the following sections, depending on the type of team you have, and the estimation unit you're using:

For Scrum teams using story points

  • The scheduler will schedule issues into the corresponding sprints, based on team velocity, sprint length, and the story points of the stories themselves.
  • The following default values will be set, though you can change these as needed:
    • Team velocity: 30 story points
    • Sprint length: 2 weeks
  • When auto-scheduling work, the team's capacity will be treated in a more precise way. The scheduler will break down the story point estimates, and then assign work to days based on how much free capacity there is in each day.
  • Any issues that don't fit into a sprint will then be assigned to the next future sprint in the timeline.
  • You can drill down in the capacity details by clicking the capacity bar of the sprint. See Understanding team capacity for more details. Note that the precise allocation of capacity (as you see in how issues are scheduled in the timeline) will not be reflected in the capacity details.
  • If an estimated epic is scheduled across multiple sprints, the proportion of the epic in each sprint will be aggregated to the relative capacity. For example, you have an epic that's estimated with 30 points, and it equally stretches across 2 sprints. Each sprint would then be allocated with 15 points. This also takes into account projected sprints.
  • When auto-scheduling a plan, the scheduler will not attempt to change or set the sprint values for issues of the epic level and higher levels.
  • If you're auto-scheduling work frequently, we recommend that you estimate issues only at the story level, and that you show rolled-up values in your plan. This avoids any duplicate values that the scheduler might take into account when auto-scheduling the issues.

See Managing capacity to understand how capacity is handled and best managed in plans with the improved interface.

For Scrum teams using time-based estimates

  • The scheduler will still schedule issues into the corresponding sprints, based on the team's weekly capacity, and the estimation of the stories themselves.
  • The team's weekly capacity is set to 200 hours by default. You can change this as needed.
  • When auto-scheduling work, the team's capacity will be treated in a more precise way. The scheduler will break down the time-based estimates, and then assign work to days based on how much free capacity there is in each day. For example, if ABC-123 has an estimate of 6 hours, and there's only 2 hours of free capacity for 27th May 2019, then the scheduler will schedule 2 hours on 27th May, and 4 hours on 28th May.
  • Any issues that don't fit into a sprint will then be assigned to the next future sprint in the timeline.
  • You can drill down in the capacity details by clicking the capacity bar of the sprint. See Understanding team capacity for more details. Note that the precise allocation of capacity (as you see in how issues are scheduled in the timeline) will not be reflected in the capacity details.
  • When auto-scheduling a plan, the scheduler will not attempt to change or set the sprint values for issues of the epic level and higher levels.
  • If you're auto-scheduling work frequently, we recommend that you estimate issues only at the story level, and that you show rolled-up values in your plan. This avoids any duplicate values that the scheduler might take into account when auto-scheduling the issues.

See Managing capacity to understand how capacity is handled and best managed in plans with the improved interface.

For Kanban teams

  • The scheduler will schedule issues on a per day basis, based on the team's weekly capacity, and the estimation of the stories themselves.
  • The team's weekly capacity is set to 200 hours by default. You can change this as needed.
  • When auto-scheduling work, the team's capacity will be treated in a more precise way. The scheduler will break down the time-based estimates, and then assign work to days based on how much free capacity there is in each day. For example, if ABC-123 has an estimate of 6 hours, and there's only 2 hours of free capacity for 27th May 2019, then the scheduler will schedule 2 hours on 27th May, and 4 hours on 28th May.
  • At this time, clicking the capacity bar will only show the number of days or hours that are booked for that weekly iteration.
  • The precise allocation of capacity (as you see in how issues are scheduled in the timeline) will not be reflected in the capacity details.
  • Even if work seems to be scheduled during weekends, weekend hours aren't really taken into account when issues are auto-scheduled. This is just because work for an issue goes over the work week, and will be completed in the next week.
  • If you're auto-scheduling work frequently, we recommend that you estimate issues only at the story level, and that you show rolled-up values in your plan. This avoids any duplicate values that the scheduler might take into account when auto-scheduling the issues.

See Managing capacity to understand how capacity is handled and best managed in plans with the improved interface.

Last modified on May 15, 2020

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.