Understanding team capacity

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

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 sprints (for Scrum teams) and iterations (for Kanban teams).

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

Capacity allocation in Scrum teams

Issue estimates that span multiple sprints consume capacity from their assigned sprints

The content in this section 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

The content in this section only applies to Scrum teams.

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.

Enhanced capacity distribution EARLY ACCESS

  • The content in this section only applies if you've enabled enhanced capacity distribution as an early access feature in Portfolio for Jira.
  • Being an early access feature, this is still work-in-progress. The feature may be incomplete, or may change before becoming fully incorporated in Portfolio for Jira. Send us any feedback and suggestions you may have via the give feedback button in your plan.

At the moment, this is how capacity is allocated in a plan:

  • For Scrum teams, if an estimated issue spans multiple sprints and is not assigned to any of them, the issue equally consumes capacity from these sprints.
  • For Kanban teams, if an estimated issue spans multiple weeks, the issue equally consumes capacity from these weeks.
  • For both teams, only one assignee can work on a story or sub-task in a sprint or iteration.  However, multiple assignees can work on an issue of the epic level or higher in a sprint. For example, only Alana can work on the story IOS-03 in sprint 1. But if IOS-03 were an epic, both Alana and Emma could work on it, even if the epic were assigned to one sprint.

How enhanced sprint capacity is allocated

The following rules impact how enhanced sprint capacity is allocated for Scrum teams:

  1. Sprint assignment: If an issue is assigned to a sprint, the assigned sprint will take precedence. Capacity will be allocated to the assigned sprint first.
  2. End dates: Capacity will be allocated to issues by end dates first, with issues ending the soonest getting highest priority.
  3. Hierarchy levels: Capacity will be allocated to issues of lower hierarchy levels first.
  4. Issue ranking: Capacity will be allocated to issues that have higher ranking first.

For example, let's say you have a plan with a team of three members, Alana, Emma, and Will. They work in 2-week sprints, and have a velocity of 15 story points.

The example above shows Alana, Emma, and Will working on IOS-01 (epic), IOS-02 (story), and IOS-03 (story) across two sprints.

How capacity is allocated for sprint 1

Since the team has a velocity of 15 story points, you can think of Alana, Emma, and Will having 5 story points each in sprint 1.

Let's go through the rules on how capacity is allocated for sprint 1:

  1. Sprint assignment: In the example above, all issues aren't assigned to a sprint. Their target dates just fall within sprints 1 and 2. So we don't have to consider sprint assignment in this case.
  2. End dates: Two issues fall within the duration of sprint 1, which are IOS-01 (epic) and IOS-03 (story). With IOS-03 ending sooner than IOS-01, that means 5 story points of its estimate will be allocated to Alana.

    Now, remember that only one person can work on a story in a sprint. So, the remaining 5 story points of IOS-03 will be carried over to sprint 2.

Since IOS-01 is the only remaining issue in sprint 1, we now look at how capacity is allocated for it.

With Alana's 5 story points fully allocated to IOS-03, only Emma and Will are available to take on the 15 story points of IOS-01. Both Emma and Will will consume 5 story points each, which means only 5 story points remain for IOS-01. The remaining 5 story points of IOS-01 will be carried over to sprint 2.

How capacity is allocated for sprint 2

After allocating capacity in sprint 1, these are the issues with story points that have carried over to sprint 2:

  • IOS-01 (epic), with 5 story points in sprint 2
  • IOS-03 (story), with 5 story points in sprint 2

Apart from the issues above, IOS-02 (story) is also in sprint 2, with 5 story points.

Let's go through the rules on how capacity is allocated for sprint 2:

  1. Sprint assignment: It's the same example, so all issues aren't assigned to a sprint. We don't have to consider sprint assignment in this case.
  2. End dates: The three issues fall within the duration of sprint 2. With IOS-03 ending the soonest, its remaining 5 story points will be allocated to Alana. 
  3. Hierarchy levels: The other remaining issues end at the same time, so the issue capacity will be allocated by hierarchy levels. Being a story, capacity will be allocated first to IOS-02. Its remaining 5 story points will be allocated to Emma. The remaining story points of IOS-01 (epic) will be allocated to Will.

How capacity is allocated when there are sprint assignments

Going back to the original example where you have a plan with a team of three members, Alana, Emma, and Will. They work in 2-week sprints, and have a velocity of 15 story points. Their plan shows the issues IOS-01 (epic), IOS-02 (story), and IOS-03 (story) with dates spanning three sprints. The only difference now is that IOS-03 is assigned to sprint 1, even if its dates span both sprints 1 and 2.

This is how capacity is allocated in sprint 1:

  1. Again, let's remember that only one person can work on a single story in sprint 1. But two persons can work on an epic in sprint 1.
  2. Since IOS-03 (story) is assigned to sprint 1, then its estimate of 10 story points will be allocated to Alana. Even if Alana has capacity to work on 5 story points per sprint, the whole 10 story points will still be allocated to her since only one person can work on a single story in a sprint. This also means that Alana is overbooked for sprint 1.
  3. Even if Alana is overbooked at 10 story points, Emma and Will are still available to take on the 15 story points of IOS-01. Both Emma and Will will consume 5 story points each, which means 5 story points will remain for IOS-01. The remaining 5 story points of IOS-01 will be carried over to sprint 2.
  4. The team is then overbooked by 5 story points for sprint 1.
Last modified on May 15, 2020

Was this helpful?

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