チームのキャパシティについて理解する
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).
スクラム チームでのキャパシティの取り扱い
スクラム チームは、ストーリー ポイントまたは時間のいずれかに基づいて作業を見積ります。
ストーリー ポイントを使用する場合、スプリントの期間に対してチームのベロシティが測定されます。たとえば、ベロシティが 2 週間のスプリントに対して 30 ストーリー ポイントに設定されている場合、キャパシティの詳細には、合計ベロシティに対して見積られたストーリー ポイントに関して、スプリントの埋まり具合がパーセンテージで表示されます。
ストーリー ポイントの見積りを使用しているチームのスプリントの例
時間ベースの見積り (日または時間) を使用する場合、キャパシティは 1 週間の期間に対して測定されます。たとえば、週のキャパシティが 2 週間のスプリントに対して 160 時間に設定されている場合、キャパシティの詳細には、2 週間の合計時間 (320 時間) に対して見積られた時間に関して、スプリントの埋まり具合がパーセンテージで表示されます。
時間ベースの見積り (時間) を使用しているチームのスプリントの例
カンバン チームでのキャパシティの取り扱い
カンバン チームのキャパシティは 1 週間の期間に対して測定されます。カンバン チームの週のキャパシティ (日または時間) を設定できる場合であっても、イテレーションの長さは変えられないので、長さは 1 週間のままとなります。
1 週間のカンバン チームの見積り時間の例
上記の例では、キャパシティは週あたり 200 時間に設定されています。そのイテレーションにおける課題の見積り時間とステータスに基づいて、次の詳細がわかります。
- この時点で 200 時間のうち 0 時間が終了しているということは、作業の 0% が完了しているということになります。
- チームの週のキャパシティである 200 時間に対して 200 時間がコミットされているということは、その週のチームのキャパシティ全体の 100% に達しているということになります。
1 つのストーリーが複数の週にわたる場合、キャパシティはその週に均等に配分されます。
2 週間にわたるカンバン課題の例
上記の例で、課題は 100 時間かかると見積られ、2 週間にわたっています。この場合、キャパシティは 2 週間で均等に配分され、各週のキャパシティに対して 50 時間コミットされます。
スクラム チームでのキャパシティ割り当て
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.
たとえば、エピック ABC-123 が 20 日間で予定され、各スプリントには 10 日間かかるため、このエピックがスプリント 1 と 2 にわたるとします。ベロシティは各スプリントで 30 ストーリー ポイントに設定されています。
- ABC-123 がスプリント 1 に割り当てられ、見積りが 30 ストーリー ポイントである場合、30 ストーリー ポイントの見積りがスプリント 1 に割り当てられます。
- ABC-123 がスプリント 1 に割り当てられ、見積りが 50 ストーリー ポイントである場合、50 ストーリー ポイントの見積りがスプリント 1 に割り当てられます。そのため、スプリント 1 が不足し、赤いキャパシティ バーが表示されます。
複数のスプリントにわたるが、どのスプリントにも割り当てられていない課題は、スプリントからキャパシティを均等に消費します
The content in this section only applies to Scrum teams.
たとえば、エピック DEF-123 が 20 日間で予定され、各スプリントには 10 日間かかるため、このエピックがスプリント 1 と 2 にわたるとします。
DEF-123 がどちらのスプリントにも割り当てられない場合、30 ストーリー ポイントの見積りは 2 つのスプリントに均等に配分されます。スプリント 1 は 15 ストーリー ポイントを割り当てられ、残りの 15 ストーリー ポイントはスプリント 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:
- 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.
- End dates: Capacity will be allocated to issues by end dates first, with issues ending the soonest getting highest priority.
- Hierarchy levels: Capacity will be allocated to issues of lower hierarchy levels first.
- 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:
- 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.
- 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:
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- The team is then overbooked by 5 story points for sprint 1.