アジャイルキャパシティ計算 — パート1/2

の容量 使い勝手のいい チームは、その期間中にどのくらいの作業負荷を担うべきかをチームに知らせるために使用すべき重要な指標です。 スプリント計画会議 今後のスプリントに向けて。キャパシティとワークロードのバランスが取れていない場合は、チームメンバーはプロダクトオーナーと十分な情報に基づいた話し合いを行い、バランスの取れた方法を検討する必要があります。

容量計算には3つの方法があります。

• 方法1： 容量を推定したり計算したりする必要はありません。これは理想的でシンプルな方法です。
• 方法2： キャパシティは、少数のパラメータを用いて（時間数で）見積もられます。これは、アジャイルチームのスプリントにおけるキャパシティを概算しながらも迅速に見積もる方法です。
• 方法3： キャパシティは、非常に包括的で拡張性とカスタマイズ性に優れたパラメータセットを用いて、時間単位で正確に計算されます。これは、スプリントにおけるアジャイルチームのキャパシティを正確に計算する方法です。実際の計算はExcelテンプレートを用いて非常に迅速に行うことができます。

2部構成のブログシリーズの最初の部分では、方法1と2を紹介します。方法3については、 第2部パート 2 の最後では、アジャイル チームの具体的な状況に基づいて、どの方法を選択すればよいかについて推奨事項を示します。

方法 1: 容量を見積もったり計算したりする必要はありません。

最もシンプル（かつやや理想化）な、よくまとまったアジャイルチーム、つまり、メンバーが過去に何度かアジャイルチームとして共に活動し、安定したベロシティを達成してきたチームを例​​に考えてみましょう。例えば、あるアジャイルチームが過去4回のスプリントで活動し、計測されたベロシティが19、21、20、19ストーリーポイントといった狭い範囲（±10%以内）に収まっているとします。この場合、チームの平均ベロシティ（過去4回のスプリントの平均）は（19+21+20+19）/4 = 19.75 = 約20となります。

同じチーム (まったく同じメンバー) が次のスプリントでチームとして作業する予定であり、次のスプリントで利用可能な作業日数が過去数回のスプリントと同じであり、チーム メンバーが大きな作業のためにプロジェクトから引き抜かれる予定がない場合、このような理想的なシナリオでは、アジャイル チームは次のスプリントで 20 ストーリー ポイント相当の作業を無理なく計画できます。

この方法では、次のようないくつかの理想的な仮定が満たされていると想定されるため、今後のスプリントのチームの実際の能力を推定または計算する必要はありません。

• よくまとまったアジャイル チームは安定した速度を達成しており、過去 4 回のスプリントで測定された平均速度は、次のスプリントの推定速度の先行指標となります。
• 次のスプリントでも、同じまとまりのあるチームが作業します。つまり、まったく同じメンバーが継続します。
• 次のスプリントで利用可能な労働日数は、過去数回のスプリントの労働日数に非常に近いです。つまり、次のスプリントでは会社の休日数が異常に多くなることはなく、チーム メンバーが長い個人休暇を取ることは予想されず、チーム メンバーがスプリント作業以外の他の割り当てのために能力を失うことも予想されません。
• テクノロジー プラットフォームは次のスプリントでも同じままになります (前回のスプリントからの変更はありません)。
• 次のスプリントでは、チーム メンバーによる新しいドメイン知識は必要ありません。

方法 2: 少数のパラメータを使用して、容量を時間数で推定します。

この方法は、方法1を正当化する1つ以上の仮定が真実でない場合、または少なくとも疑わしい場合に適用できます。以下の条件の1つ以上に該当する場合、方法1は使用しないでください。

• アジャイル チームはまだまとまったチームではありません。過去には、スプリントごとに速度が不規則に変化することを経験しています。
• アジャイル チームの構成は、前のスプリントから次のスプリントでは変更される可能性が高く、これによりチームのダイナミクスとチームの生産性が確実に変化します。
• 今後のホリデーシーズン、夏休み、冬休みなどの影響により、次のスプリントのチームのキャパシティは前回のスプリントと異なることが予想されます。
• チームメンバーは、次のスプリント中に異なるテクノロジー プラットフォームで作業することが期待されます。
• 次のスプリントに向けて、1 人以上のチーム メンバーが新しいドメイン知識を学習して適用する必要があります。

このようなシナリオでは、過去の平均速度を今後のスプリントの推定速度の先行指標として用いることはできません。今後のスプリントでチームが実際のハンズオン作業に使用できる時間を見積もる必要があります。この手法では、組織内の過去のデータ（データが存在し、利用可能な場合）に基づいて、簡略化されたモデルを使用します。過去のデータに基づくと、チームは8時間のうち60%から80%を実際のハンズオン作業に使用できる時間として使用できます。残りの時間（40%から20%）は、一般的なメールや電話のやり取り、社内会議、日々の業務の準備と参加に充てられます。 スクラム 会議など。そのため、フルタイムのチームメンバー1人あたり、1日あたり4.8時間から6.4時間（週40時間労働の場合は24時間から32時間）の実作業時間があると見積もられます。例えば、アジャイルチームにフルタイムメンバーが8人いて、4週間のスプリントを採用している場合、翌週のキャパシティは8×4×24＝768時間（実作業が60%の場合）、または8×4×32＝1,024時間（実作業が80%の場合）と見積もられます。

これはアジャイルチームのキャパシティの大まかな見積もりに過ぎないことに注意してください。これは単一のパラメータ（組織の過去のデータに基づくと、実務に使える時間の割合、通常は60%から80%）に基づいているためです。過去のデータが利用できない場合、組織によっては、事例証拠やその数値に対する安心感に基づいて、推定値（例えば75%）を使用する場合があります。

推定キャパシティ数値は、アジャイルチームに対し、今後のスプリントでどれだけの作業量（実装するストーリーや機能、修正する不具合）を計画できるかという指針を提供するために使用されます。例えば、チームのキャパシティが800時間と推定される場合、推定作業時間も800時間に近い値にする必要があります。チームはキャパシティを超過しても構いませんが、5%を超えることはありません。つまり、この例では、推定作業時間は840時間を超えてはなりません。

アジャイルチームは、優先順位付けされたスプリントバックログに基づいて、計画された作業時間を見積もったり計算したりする必要があります。各ストーリーと欠陥の工数は、経過時間ではなく理想時間で見積もる必要があります。これは、チームが関連する作業に関する共通の知識に基づいて、ストーリーまたは欠陥レベルで行うことができます。あるいは、各ストーリーと欠陥をタスクとテストに分割し、各タスクとテストを理想時間で見積もった後、それらの見積りを合計して、ストーリーまたは欠陥の工数を理想時間で見積もることもできます。

方法2は、単一または少数のパラメータに基づいてキャパシティの推定値を提供するだけなので、あくまでも概算値です。包括的なパラメータセットに基づいて、チームのキャパシティを時間単位で正確に推定する必要がある場合は、方法3に従う必要があります。この方法については、 第二部 この 2 部構成のブログ投稿の。