Understanding sprints
The content on this page only applies to Scrum teams.
Scrum teams work in sprints (or iterations), and these teams release incremental features of their product at the end of each sprint. If you're planning work for Scrum teams, we recommend that you use boards as the issue sources in your plan (instead of projects or filters).
Using Scrum boards as issue sources lets you manage the sprints that come from those boards, plan the capacity of future sprints, and assign issues to sprints — all directly from your plan. More importantly, if you use the project as an issue source, Advanced Roadmaps cannot readily associate the sprints of that board with the project. The sprints will then appear as external sprints in your plan. See Scheduling issues according to sprints to learn more about using external sprints in Advanced Roadmaps.
On this page:
- What is a sprint?
- Viewing sprints
- Sprint states
- Estimation and velocity in sprints
- Editing sprint capacity
- Scheduling issues according to sprints
What is a sprint?
A sprint is a fixed period of time during which a Scrum team works on issues that they've committed to complete during that period. The issues can be feature stories or bug fixes, depending on how the team works. At the end of the sprint, what typically happens is the Scrum team bundles up all the issues they've completed, and will then release this bundle as a version of their software product.
In both Jira and Advanced Roadmaps, a sprint is a 2-week period by default, which is essentially 10 working days.
A team’s default sprint length can be edited in the Teams view in . Learn more about managing teams in a plan.
Viewing sprints
Make sure you've already grouped issues by teams so you can view the sprints for each team in the plan. The issues will be grouped in swimlanes by teams, and the capacity details for each sprint will be displayed.
- Issues are grouped in team swimlanes. Expand the team to show the issues assigned to that team.
- Clicking the capacity bar of a sprint will display the capacity details for each sprint.
If you've configured the plan to show rolled-up values, then sprint valueswill be rolled up, from child issues up to the corresponding parent issues.
Sprint states
In Advanced Roadmaps, sprints are represented in 4 different states — past sprints, active sprints, future sprints, and projected sprints.
Past sprints
If a team has not defined any sprints in the past, but already has some current and future sprints set up, Advanced Roadmaps will display “past sprints” in the timeline. The dates of past sprints are inferred based on the sprint duration and velocity set for the team.
Sample past sprint in the timeline of a plan
Since past sprints do not exist, there are no capacity details to display.
Active sprints
Any sprint that is currently in progress in Jira will be displayed as an active sprint in the timeline of an Advanced Roadmaps plan.
When auto-scheduling work in a plan, Advanced Roadmaps is able to auto-schedule issues into these active sprints based on the sprint duration and velocity set for the team. Any issues that go beyond the velocity of active sprints will be allocated into future sprints or projected sprints.
Sample active sprint in the timeline of a plan
Sprint details include:
sprint name
sprint start and end dates
active sprint lozenge
sprint goal (if added in Jira)
- sprint velocity (with the velocity set to 20 story points)
- percentage of how full the sprint is in estimated story points
percentage of issues that have been completed
You can choose to view the sprint in Jira, filter the issues in your plan by this sprint, or view the velocity chart of the associated sprints.
If there’s any unexpected change in a team’s capacity (for example, when 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 and is scheduled after a currently active sprint, will be displayed as a future sprint in the timeline.
Even though a sprint can only be given its dates when it becomes active, Advanced Roadmaps is able to infer the dates of future sprints based on the sprint duration and velocity set for the team. This is why future sprints can be displayed in the timeline.
Based on the sprint duration and velocity set for the team, Advanced Roadmaps is able to auto-schedule work into these future sprints as needed. Any issues that go beyond the velocity of active sprints will be allocated into these future sprints.
Sample future sprint in the timeline of a plan
Sprint details include:
sprint name
sprint start and end dates
future sprint lozenge
sprint goal (if added in Jira)
- sprint velocity (with the velocity set to 20 story points)
percentage of how full the sprint is in estimated story points
You can choose to view the sprint in Jira, filter the issues in your plan by this sprint, or view the velocity chart of the associated sprints.
If there’s any fluctuation in a team’s capacity (for example, when team members go on annual leave), you can quickly update the sprint capacity in the future sprint’s menu.
Projected sprints
Since Advanced Roadmaps can infer the dates of sprints that can happen in the future, any sprints that are projected to happen after future existing sprints will also be displayed in the timeline.
Because these sprints do not exist in Jira, they will be displayed as projected sprints. Note, the name of the sprint will be "Projected sprint" because the sprint does not exist in the first place.
Based on the sprint duration and velocity set for the team, Advanced Roadmaps is able to auto-schedule work into these projected sprints as needed. Any issues that go beyond the velocity of existing future sprints will be allocated into these projected sprints.
You can choose to filter the issues by the sprint in your plan.
Sample projected sprint in the timeline of a plan
Sprint details include:
sprint name
sprint start and end dates
projected sprint lozenge
Estimation and velocity in sprints
There are several ways to estimate the issues you're working on. Depending on how your team works, you can estimate issues using story points or time-based estimates (days or hours).
The main objective though should be to get better at predicting how much work a team can complete in each sprint. This translates to knowing the team's velocity.
Velocity measures the number of estimation units that a team usually completes from sprint to sprint. It is effectively a productivity rate based on an estimation of volume of work, and it is best worked out in a measure other than time.
We recommend using story points instead of time-based estimates. If you estimate that a story will take 16 hours to complete, there's no guarantee that estimate is 100% accurate. Story points, on the other hand, focus on estimating the size of an issue. A trivial bug fix may be estimated at 1 or 2 story points. A bigger feature that needs some prior research, however, may be estimated at 8 or 10 story points. Learn more about story point estimation.
Editing sprint capacity
When planning a team’s work, it’s important that sprint details are as accurate as possible so that planned work can commence as scheduled. While a team’s sprint velocity might be 20 story points on average, this can fluctuate due to various factors. In the short term, a public holiday might shorten the working week, a team member could become sick, or new team members might not complete work as fast while they’re in training. In the longer term, team members might take extended leave, switch teams, or be spread across different projects.
In these situations, you can keep the sprint (and therefore, your plan) accurate by editing a team’s capacity. This can be done for active and future sprints directly in your plan’s timeline.
Sprint menu for a future sprint
To edit a team’s capacity, go to the sprint’s menu on the timeline, and click on the sprint velocity to enter a new value. Click the checkmark to save and see how the edited capacity affects planned work in your timeline. If everything looks good, go ahead and save the change in Jira.
Note that if a sprint’s capacity is not changed in this menu, the sprint will have the default capacity set in the Teams view.
Scheduling issues according to sprints
Before you begin, note that this only applies to issues sourced from Scrum boards and when issues are assigned to Scrum teams.
Scrum teams work in sprints (or iterations), and they release incremental features of their product at the end of each sprint. When a team and a sprint are set for an issue, you can configure a plan to use sprint dates for issues that don't have any dates set yet.
- Even if an issue is showing its sprint dates, you can still change its dates if needed. Note that if the dates no longer match the sprint dates, this will not change the sprint assignment of the issue.
- Sprint dates will also be used when monitoring the status of releases and keeping track of issue dependencies.
See Scheduling issues for more details.