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 a Scrum team.

#1 Scrum teams have a choice of estimating work in either story points or time-based estimates (days or hours)

When using story point estimates, team velocity would be measured against the 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.

ストーリー ポイントの見積りを使用しているチームのスプリントの例

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.

時間ベースの見積り (時間) を使用しているチームのスプリントの例

#2 An issue that spans multiple sprints will have its estimate consuming capacity from the sprint that's assigned to it

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.

#3 An issue that spans multiple sprints, and is not assigned to any of these sprints, will have its capacity equally distributed among the sprints

This only applies to Scrum teams.

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 — the iteration will always be 1 week long.

If weekly capacity is set to 40 hours, when you hover over one of the capacity bars in the timeline, the number of hours that have been estimated for that week will be displayed.

1 週間のカンバン チームの見積り時間の例

If a story spans multiple weeks, its capacity will be equally distributed among the weeks. For example, the story TIS-456 is scheduled for 10 days, so it spans 2 work weeks, with 5 days for each work week. Capacity will then be equally distributed among the 2 work weeks.

最終更新日 2019 年 8 月 9 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.