How does the Auto-scheduler in my plan work?

This page refers to the advanced planning features that are only available as part of Jira Cloud Premium and Enterprise.

 

The Auto-scheduler constructs a plan using issue details which you can then adjust to meet your exact needs. To do this, it balances a range of different values from the dates assigned to an issue, issue estimates, a team’s capacity and velocity, and any dependencies between issues. There isn’t one aspect that the Auto-scheduler focuses on, but rather takes all of them in aggregate.

However, one requirement for all issues is that they have a To Do or In Progress status. Issues with Done statuses are ignored by the Auto-scheduler. Beyond this, you can select which issues you want the Auto-scheduler to work on by selecting issues in the Scope column before using it. If you select none, the Auto-Schedule works on your whole plan.

By default, the Auto-scheduler schedules all issues in your plan, regardless of whether you’ve set dates for them. To exclude already-scheduled issues from the Auto-scheduler, you’ll need to choose which issues the Auto-scheduler can overwrite. See how to configure the Auto-scheduler.

This is just the tip of the iceberg. On this page, we’ll cover the following topics:

How the Auto-scheduler handles dates

When scheduling issues, the Auto-scheduler looks at the issue’s start and end date if there’s no estimation defined. If it has none, then the Auto-Scheduler looks for a sprint assignment, and assigns it those dates. If it has no sprint assignment or assigned dates, the Auto-Scheduler checks to see if it’s included in a release, and then assign the dates of the release.

How the Auto-scheduler allocates capacity

In order to allocate capacity, your issues need to have an estimate. Issues without estimates may still be scheduled according to dates, but won’t be included in capacity calculations.

The Auto-scheduler assigns capacity in a sprint on a first-come, first-serve basis, with priority given to:

  • issue rank as defined on your timeline

    • the Auto-Scheduler starts at the top of your plan and works its way down based on issue rankings; issues ranked higher are scheduled first. Read more about issue ranking.

  • an issue’s estimation

  • issues of lower hierarchy levels (stories or subtasks take priority over epics or initiatives)

    • for the reasons discussed below, we recommend that you only estimate issues at the story level, and that you show rolled-up values in your plan

Outside of these main pillars, the Auto-scheduler also considers other plan data:

  • Issue source assignment

    • teams associated to an issue source (board, project, or filter) are prioritized when assigning work

  • Team velocity

    • a higher team velocity means that more work can be done in one sprint

  • Number of team members

    • since the Auto-scheduler assumes that one person can handle one story-level issue at a time, the number of team members affects how many issues can run in parallel

  • Sprint information

    • sprint duration and capacity

  • Releases

    • if this field is empty, the Auto-scheduler assigns an issue to the next available release

  • Dependencies

    • if two issues are dependent on each other (also known as a cyclical dependency), they’ll be ignored by the Auto-scheduler; examples include:

      • issue A blocks issue B, and issue B blocks issue A

      • a story has a dependency to its own subtask

How the Auto-scheduler handles higher hierarchy levels

As covered above, the Auto-scheduler assumes that one person can work on one task when dealing with story-level issues. This isn’t the case when working with hierarchy levels above epic; if your plan includes an estimated issue at the epic-level or above, the Auto-scheduler schedules the issue according to the team’s full capacity, as it assumes that everyone can work simultaneously on it.

If, in the example above, the issue that you estimated at 10 story points was an epic (instead of a story-level issue), the Auto-scheduler would assign it one sprint instead of three.

To resolve this, we recommend that you only estimate issues at the story level, and that you show rolled-up values in your plan.

How the Auto-scheduler handles active sprints

This is a common source of unexpectedly overbooked sprints.

The Auto-scheduler handles active sprints differently than future planned sprints.

First of all, the Auto-scheduler won’t reschedule issues in the active sprint, even if it’s overbooked.

Secondly, the Auto-scheduler won’t overwrite any values of issues in the active sprint. Sprint, Team, and Release can only be overwritten in the active sprint if the field is empty. See how to configure the auto-scheduler.

How the Auto-scheduler handles capacity

This is a common source of unexpectedly overbooked sprints.

The Auto-scheduler handles capacity based on the capacity distribution algorithm. Read more about how capacity is distributed in plans.

 

Still need help?

The Atlassian Community is here for you.