Understanding sprints

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

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 highly recommend that you use the corresponding boards as the issue sources in your plan, and not projects.

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, the scheduler cannot readily associate the sprints of that board with the project. The sprints will then appear as external sprints in your plan.

On this page:

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 Portfolio for Jira, a sprint is a 2-week period by default, which is essentially 10 working days. Depending on team size and capacity, you can adjust the number of days in a sprint as needed.

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.

  1. Issues are grouped in team swimlanes. Expand the team to show the issues assigned to that team.
  2. Clicking the capacity bar of a sprint will display the capacity details for each sprint.
  3. If you've configured the plan to show rolled-up values, then sprint values will be rolled up, from child issues up to the corresponding parent issues.

    If an issue is assigned to multiple sprints, and one of these sprints has already been completed, the completed sprint will be displayed in grayed out text. If the multiple sprints have already been completed, the name of the most recently completed sprint will be displayed.

Types of sprints

When planning work for multiple teams, several types of sprints are taken into account.

Past sprints

If a team has not defined any sprints in the past, but it already has a currently active sprint and some sprints following that, these past sprints will be displayed in the timeline. Portfolio for Jira can infer the dates of these past sprints, based on the sprint duration and velocity set for the team, and can thereby display these past sprints.

Sample past sprint in the timeline of a plan

Since past sprints do not exist, there are no capacity details to display.

Completed sprints

Any sprints that have been completed in Jira will display as completed sprints in the timeline of a Portfolio for Jira plan. You can choose to view the sprint report in Jira, as well as filter the issues by the sprint in your plan.


Sample completed sprint in the timeline of a plan

Sprint details include:

  • sprint name

  • sprint start and end dates

  • completed sprint lozenge 

  • sprint goal (if added in Jira)

By default, completed issues disappear from the plan 30 days after completion. Though this setting can be configured, this means that the capacity details of a completed sprint will not take into account any completed issues assigned to that sprint that are no longer in the plan.

Active sprints

Any sprints that are currently in progress in Jira will be displayed as active sprints in the timeline of a plan. A sprint is only given its start and end dates when it becomes active.

Based on the sprint duration and velocity set for the team, Portfolio for Jira is able to auto-schedule work into these active sprints as needed. Any issues that go beyond the velocity of active sprints will be allocated into future sprints or projected sprints.

You can choose to view the sprint in Jira, as well as filter the issues by the sprint in your plan.


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)

  • percentage of issues that have been completed

  • percentage of how full the sprint is in estimated story points (with the default velocity set to 30 story points)

  • number of unestimated issues in the sprint

  • number of unassigned issues in the sprint

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, the dates of future sprints can be inferred 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, issues can be auto-scheduled into these future sprints as needed. Any issues that go beyond the velocity of active sprints will be allocated into these future sprints.

You can choose to view the sprint in Jira, as well as filter the issues by the sprint in your plan.


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)

  • percentage of how full the sprint is in estimated story points (with the default velocity set to 30 story points)

  • number of unestimated issues in the sprint

  • number of unassigned issues in the sprint

Projected sprints

Since the scheduler is able to infer the dates of sprints that can happen in the future, any sprints that are projected to happen after future existing sprints can will also be displayed in the timeline.

Because these sprints do not exist in Jira, they will display 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, Portfolio for Jira 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

  • percentage of how full the sprint is in estimated units

  • number of unestimated issues

  • number of unassigned issues

External sprints

If a plan is using projects or filters as issue sources, sprint data will still be displayed for the corresponding issues. However, the sprints will be displayed with the  lozenge next to them, which means these are external sprints.

Because sprints can only be directly associated with board issue sources, then the lozenge indicates that the sprints are directly associated with project and filter issue sources.

Issues assigned to an external sprint

See Scheduling issues according to sprints for more details on handling external sprints.

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.

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.

Sample plan with target dates of issues aligning with sprint dates

  • 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.

Last modified on Mar 25, 2020

Was this helpful?

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