Understanding team capacity

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

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.

Last modified on Mar 25, 2020

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.