Understanding team capacity
To manage the capacity of multiple teams in your plan, we recommend that you understand the concept of capacity in the improved interface. Team capacity is defined as the ratio of 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 show team capacity in the timeline, capacity bars display and show how work is distributed across the corresponding duration. For Scrum teams, duration would be sprints, and for Kanban teams, duration would be iterations.
How capacity is handled in 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, the capacity details show the percentage of how full the sprint is in terms of the estimated story points against 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. For example, if weekly capacity is set to 160 hours for a 2-week sprint, 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)
How capacity is handled in 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's no way to change the iteration length so 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:
- At the moment, 0 of 200 hours is done, which means 0% of the work has been completed.
- 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 100 hours, and it spans spans 2 weeks. Capacity will then be equally distributed among the 2 work weeks, with 50 hours committed against the capacity of each week.
Other things to know about capacity
Issue estimates that span multiple sprints consume capacity from its assigned sprint
This only applies to Scrum teams and to issues of the epic hierarchy level and above.
For example, the epic ABC-123 is scheduled for 20 days, and spans across sprints 1 and 2 because each sprint runs for 10 days. The velocity is set to 30 story points for each sprint.
- If ABC-123 is assigned to sprint 1 and has an estimate of 30 story points, its estimate of 30 story points will be allocated to sprint 1.
- If ABC-123 is assigned to sprint 1 and has an estimate of 50 story points, its estimate of 50 story points will be allocated to sprint 1. Sprint 1 will therefore be overbooked, and will display a red capacity bar.
Issues that span multiple sprints and are not assigned to any sprints, will equally consume capacity from the sprints
For example, the epic DEF-123 is scheduled for 20 days, and spans across sprints 1 and 2 because each sprint runs for 10 days.
If DEF-123 is not assigned to either sprint, its estimate of 30 story points will be equally distributed across the 2 sprints. Sprint 1 will be allocated 15 story points, and the remaining 15 story points will be allocated to Sprint 2.