Displaying capacity in a plan
In plans with the improved interface, capacity is directly associated with teams — there is no concept of individual capacity; capacity is measured as a whole for the team.
To display team capacity in your plan, you must:
- Group the issues in your plan by teams via the view settings of the plan,
- and then configure your plan to show team capacity on the timeline.
The issues will then be grouped and displayed into team-specific swimlanes in the plan. The teams in the plan have their own swimlanes, and you can view its assigned issues by expanding each team.
However, you need to make sure that you've already associated the teams in your plan to the corresponding issue sources. Only then will team capacity be shown in the timeline. This can help you visualize how team-specific work is distributed across the multiple sprints of each team.
At the moment, capacity details can only be shown for Scrum teams, and not Kanban teams.
Showing capacity in the timeline
- In the roadmap view of the plan, click View settings.
- From the 'Group by' menu, choose Team. The issues in the plan will be grouped into team-specific swimlanes.
- Select the Show capacity on timeline checkbox. This will display the sprints associated to the teams in the plan.
Sprints will only be displayed if the corresponding issue sources are already associated to the teams. See Creating teams for more details.
Impact of auto-scheduling on capacity in the timeline
When auto-scheduling issues, the auto-scheduled results could potentially affect how capacity is displayed in the timeline. The important thing to note here is that the work that's auto-scheduled is not reflected in the capacity details of each sprint or iteration.
- How capacity is measured would depend on the type of the team (Scrum or Kanban), and how the team estimates work (story points vs time-based estimates).
- If the team is using story points for estimation, then capacity is based on team velocity, and would then be measured against the duration of the sprint.
- If the team is using time-based estimates, then capacity is measured against the duration of a week.
- Fo Scrum teams, story-level issues only consume capacity if these issues are explicitly assigned to a sprint.
- If the target dates of an issue span multiple sprints, its estimate will consume capacity from the sprint that's assigned to it.
- If an issue above the story level spans multiple sprints, and is not assigned to any of these sprints, then its capacity will be equally distributed among the sprints.
- For Kanban teams: if an issue spans multiple weeks, its capacity will be equally distributed among the weeks.
See Understanding team capacity for more details.
This can be illustrated more clearly in the following examples:
Example #1 When planning high-level work across multiple sprints
When you're in the earlier stages of planning work for a team, you may just be creating epics or initiatives with a high-level, rough estimate for these issues.
Let's say you've created the epic ABC-123, and this epic spans 3 sprints, with an estimate of 18 story points. Note that ABC-123 is just one of the many epics and initiatives that you've created in your plan. When you auto-schedule your plan, Portfolio can actually figure out the individual workload for ABC-123 for each sprint.
Based on the factors that Portfolio considers when auto-scheduling a plan, let's say that for ABC-123, the following are auto-scheduled into each sprint:
- For sprint 1, 5 story points
- For sprint 2, 10 story points
- For sprint 3, 3 story points
Even if the estimate of the epic is distributed among the 3 sprints this way, capacity will still appear as evenly distributed across the 3 sprints in the timeline. In other words, the granular breakdown on how much work is assigned to each of the sprints is not reflected in the capacity details of each sprint.
Example #2 When auto-scheduling stories into projected sprints
Based on the sprint duration and velocity or weekly capacity of a team, Portfolio is able to auto-schedule stories into projected sprints. Even if this is so, capacity is only consumed for stories that are assigned to actual sprints, which essentially means that capacity can only be consumed against real future sprints — these are future sprints that truly exist in Jira.
Because of this, any issues that are auto-scheduled into projected sprints will not have its corresponding capacity reflecting accurately in the timeline.
More notes on sprints and capacity
- If your teams are working on parallel sprints in Jira, these sprints will appear independently in the timeline.
- All the sprints associated with a team will appear in the timeline, which means your timeline might be filled with a lot of sprints, and might end up too crowded. To handle this, consider viewing issues for just a specific timeframe.
- When a sprint is completed, the sprint will be visualized on the timeline as finishing at the end of the day before it was completed. Effectively, this prevents sprints from appearing to overlap on the timeline. This visualization applies whether your issues are scheduled through sprint assignment, or you're manually scheduling the issues themselves.