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.
On this page, we cover the following:
- Schedule using start and end dates
- Schedule issues according to sprints
- Sprint states
- External sprints
- External teams
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.
Sprints are represented in five different states: past sprints, completed sprints, active sprints, future 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 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.
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.
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.
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 are determined by Jira issues that have both the start and end dates set, or will be inferred based on your capacity settings.
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.
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.
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.