Schedule issues

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

An important aspect of planning work is scheduling how long each issue will take to complete. How you schedule issues depends on how your teams are set up, and how you’ve configured your instance. For example, hierarchy configurations, estimation units, and custom dates all must be configured before they can be used to schedule issues in your plan.

Advanced Roadmaps can also assist you in scheduling issues using features like the Auto-scheduler and rolling up values to parent issues.

On this page, we cover the following:

Schedule using start and end dates

The easiest way to schedule an issue is to add a value to the start date and end date fields on your timeline. Once you’ve scheduled child issues, you can then use the Rolling-up values to parent issues feature to extrapolate dates of the parent issues.

Alternatively, use your mouse to place a schedule bar on your timeline which you can then expand or contract to change the issue’s duration.

Schedule issues according to sprints

This only applies to Scrum teams.

Once configured by your administrator, you can tell Advanced Roadmaps to schedule issues to sprints provided the issues have a sprint and team assignment but no due dates. When Advanced Roadmaps uses sprint dates, the start and end date columns in your plan will display an S lozenge.

From here, you can then change an issue’s dates manually without changing its sprint assignment. However, if the new dates fall before or after the sprint, you’ll see a warning.

When a sprint is completed, it will appear as finished on the last day. This prevents sprints from overlapping on the timeline and applies whether your issues are scheduled manually or through sprint assignment.

Sprint states

Sprints are represented in five different states: past sprints, completed sprints, active sprintsfuture sprints, and projected sprints. Understanding the difference between these sprint states is essential when assigning capacity to sprints and monitoring capacity from your timeline

Past sprints

Past sprints are unnamed representations of what past iterations would have been if the sprints existed at that point. They're created based on sprint length and are used for demonstration purposes only. The sprint capacity window won’t appear when you hover over the sprint status bar.

Completed sprints

While past sprints are representations of past iterations, Completed sprints are scheduled sprints that have been completed by your team. You can hover over completed sprints to see details, but you can’t change the information.

Active sprints

An Active sprint is the sprint that's currently in progress and has an ACTIVE SPRINT lozenge next to the dates.

When auto-scheduling work in a plan, issues will be scheduled into the next available future sprint, based on the remaining sprint capacity. Issues won’t be assigned to a currently active sprint.

If there’s any unexpected change in a team’s capacity (for example, a team member is sick), you can quickly update the sprint capacity in the active sprint’s menu.

Future sprints

Any sprint that already exists in Jira Software and is scheduled after the active sprint is called a Future sprint and will have a FUTURE SPRINT lozenge next to its name. Dates of future sprints will show on your timeline as defined on the Jira Software board. If you don't set a date in Jira Software, dates of future sprints are inferred based on your capacity settings and issues that have both the start and end dates set. 

Projected sprints

Any sprints that are projected to take place beyond the scope of existing future sprints will also be displayed in the timeline. These are called Projected sprints and will have a PROJECTED SPRINT lozenge next to the dates.

External sprints

If you use projects or filters as your issue sources, their sprint assignments will still show on your plan. However, since sprint data is based on boards, Advanced Roadmaps will add the EXTERNAL lozenge to indicate that these sprints are not directly associated with the project and filter issue sources. You can update the sprint values of the issues assigned to these external sprints. However, you can’t assign new issues in your plan to an external sprint.

To avoid creating external sprints, we recommend that you use boards as issue sources where possible as a board only covers one sprint. Issues imported from projects and filters may comprise multiple sprint assignments which will show on your timeline as external sprints.

Troubleshoot external sprints

There are two main reasons you may see external sprints on your plan:

  • One of your future sprints appears on another Scrum board

  • One of the teams for which you’re planning future sprints has a different iteration length configured

If either or both of these are true, and you use Group issues by team and Show capacity on the timeline to plan future sprints based on capacity and velocity, the common sprint will occur at different times in each team swimlane. To compensate for this inconsistency in planning, Advanced Roadmaps will automatically create an external sprint because the same sprint can’t have two different start and end dates.

This issue will resolve itself once a future sprint becomes an active one.

External teams

When an issue is assigned to a team that’s not part of your plan, it shows as an external team. To unlock the full planning capabilities for these teams in your plan, you first must add them using the Teams tab.

Last modified on Sep 6, 2021

Was this helpful?

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