Understanding team capacity
To manage the capacity of the multiple teams in your plan, we recommend that you have a good grasp of the concept of capacity in the improved interface. As already discussed, team capacity is the ratio of the units of work that a team takes on for a given period of time against the maximum units of work that a team can take on for that given period of time.
When you're showing team capacity in the timeline, capacity bars will display in the timeline, and these bars will reflect how work is distributed across the corresponding duration.
For Scrum teams, this duration would be sprints. While for Kanban teams, this duration would be iterations. This is the basic premise on how work is distributed for both types of teams. There are small differences on how capacity is represented across both types of teams:
Capacity details of Scrum teams
These are some details to take note of when managing the capacity of Scrum teams.
Scrum teams estimate work in either story points or time-based estimates
When using story points, team velocity is measured against sprint duration.
For example, if velocity is set to 30 story points for a 2-week sprint, then the capacity details will show the percentage of how full the sprint is in terms of the estimated story points against the total velocity.
Sample sprint of a team using story point estimates
When using time-based estimates (days or hours), capacity is measured against the duration of a week.
If weekly capacity is set to 160 hours for a 2-week sprint, then the capacity details will show the percentage of how full the sprint is in terms of the estimated hours against the total hours (320 hours) for the 2 weeks.
Sample sprint of a team using time-based estimates (hours)
The estimate of an issue that spans multiple sprints will consume capacity from its assigned sprint
This only applies to Scrum teams, and to issues of the epic hierarchy level and above.
For instance, the epic TIS-123 is scheduled for 20 days, and it spans sprints 1 and 2 because each sprint runs for 10 days. Let's also say that velocity is set to 30 story points for each sprint.
- If TIS-123 is assigned to sprint 1, and has an estimate of 30 story points, then its estimate of 30 story points will be allocated to sprint 1.
- If TIS-123 is assigned to sprint 1, and has an estimate of 50 story points, then its estimate of 50 story points will be allocated to sprint 1. Sprint 1 will then be overbooked, and will display a red capacity bar.
An issue that spans multiple sprints, and is not assigned to any of these sprints, will equally consume capacity from the sprints
For instance, the epic TIS-123 is scheduled for 20 days, and it spans sprints 1 and 2 because each sprint runs for 10 days.
If TIS-123 is not assigned to any of the 2 sprints, then its estimate of 30 story points will be equally distributed among the 2 sprints. Sprint 1 will be allocated 15 story points, and the rest of the 15 story points will be allocated to Sprint 2.
Capacity details of Kanban teams
Capacity for Kanban teams is measured against the duration of a week. Even if you can set the weekly capacity (days or hours) of a Kanban team, there is no way to change the iteration length, and it will stay a week long.
Sample estimated hours of a Kanban team for a week
In the example above, capacity has been set to 200 weekly hours. Based on the estimated hours and status of the issues in that iteration, the following details are known:
- 80 hours of the 200 committed hours have already been completed, which means 40% of the work is already done.
- 200 hours have been committed against the team's weekly capacity of 200 hours, which means the team's reached 100% full capacity for that week.
If a story spans multiple weeks, its capacity will be equally distributed among the weeks.
Sample Kanban issue that spans two weeks
In the example above, the issue is estimated at 300 hours, and it spans spans 2 weeks. Capacity will then be equally distributed among the 2 work weeks, with 150 hours committed against the capacity of each week.