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 Portfolio plan. More importantly, if you use the project as an issue source, Portfolio cannot readily associate the sprints of that board with the project. The sprints will then appear as external sprints in your plan.
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.
If you're working with sprints in your Portfolio plan, we recommend familiarizing yourself with the following concepts:
|Estimation and velocity||
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 translated 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 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.
Any sprints that have been completed in Jira Software will display as completed sprints in the timeline of a Portfolio plan.
Sample completed sprint in the timeline of a plan
If by chance a team has not defined any sprints in the past, but it already has a currently active sprint and some sprints following that, Portfolio will display these past sprints 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
Note that since past sprints do not really exist in the first place, so there are no capacity details that can be displayed.
Any sprints that are currently in progress in Jira Software will display as active sprints in the timeline of a Portfolio plan. Note that in Jira Software, a sprint can only be given its start and end dates when it's started, and thus become an active sprint.
Sample active sprint in the timeline of a plan
Based on the sprint duration and velocity set for the team, Portfolio 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.
Any sprints that already exist in Jira Software, and are scheduled after a currently active sprint, will display as future sprints in the timeline of a Portfolio plan.
Sample future sprint in the timeline of a plan
Even if a sprint can only be given its dates when it becomes active, Portfolio is able to infer the dates of these 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, Portfolio 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.
Since Portfolio is able to infer the dates of sprints that can happen in the future, then any sprints that are projected to happen after the future existing sprints can also be displayed in the timeline.
Because these sprints do not exist in Jira Software, these will then be displayed as projected sprints. Note, however, that the name of the sprint will just be "Projected sprint" because the sprint does not exist in the first place.
Sample projected sprint in the timeline of a plan
Based on the sprint duration and velocity set for the team, Portfolio 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.
- No matter the type of sprint, you can view the following details:
- The name of the sprint (projected sprints will be named projected sprints since these don't exist in Jira Software yet)
- The status of the sprint, where the lozenge will appear as completed, active, future, or projected next to the sprint name
- The start and end dates of the sprint
- For completed and active sprints, the percentage of issues that have been completed in the sprint
- For future and projected sprints, the percentage of how full the sprint is in terms of the estimated story points
- The number of unestimated issues and number of unassigned issues in that sprint
- For completed, active, and future sprints, you can choose to view the sprint in Jira Software.
- For all types of sprints, you can choose to filter the issues by a specific sprint in your plan.