Displaying capacity in a plan
In a plan, capacity is directly associated with teams, where capacity is measured as a whole for the team.
To display team capacity in your plan:
- Make sure you've already associated the teams in your plan with the corresponding issue sources. Only then can team capacity be shown in the timeline.
- Group the issues in your plan by teams or sprints via the view settings of the plan.
- Configure your plan to show team capacity on the timeline.
The issues will then be grouped and displayed into team-specific or sprint-specific swimlanes in the plan, and you can view its assigned issues by expanding each swimlane. This helps you visualize how team-specific work is distributed across the multiple sprints of Scrum teams, or across the multiple iterations of Kanban teams.
Showing capacity in the timeline
- In the roadmap view of the plan, click View settings.
- From the 'Group by' menu, choose Team or Sprint.
- Select the Show capacity on timeline checkbox. This will display the sprints and iterations associated to the teams in the plan in individual swimlanes.
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.
- For 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. For more information on how capacity works with Kanban teams, see Understanding team capacity.
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, the individual workload for ABC-123 for each sprint can actually be determined.
Based on the factors being considered 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, stories can be auto-scheduled 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. 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.