Understanding team capacity

Team capacity is defined as the ratio of units of work that a team takes on measured against the maximum units of work that a team can get through in that period of time.

When you show team capacity in the timeline, capacity bars display and show how work is distributed across sprints (for Scrum teams) and iterations (for Kanban teams). In this article we’ll explain how capacity is handled in both Scrum and Kanban teams.

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 2 weeks. Capacity will then be equally distributed among the 2 work weeks, with 50 hours committed against the capacity of each week.

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)

Capacity allocation in Scrum teams

Capacity is distributed evenly across sprints unless issues are assigned to a sprint. If there is no sprint assignment, story points are allocated as follows, in this order:

• End dates — If issues have no sprint assignment, they’re prioritised based on end dates, with issues ending the soonest getting highest priority.
• Hierarchy levels — If there’s no sprint assignment and no end dates, issues are sorted by hierarchy level in reverse order. For example, a story is given higher priority than an epic.
• Issue ranking — Naturally you will have multiple issues with the same hierarchy level, and this is where issue ranking comes in. Capacity will first be allocated to the lowest hierarchy issues with the highest rank.