スクラムにおけるベロシティとは何ですか？

ベロシティは、スクラム開発チームが時間の経過とともにビジネス価値をどれだけ迅速に提供できるかを正確に測定する、非常にシンプルだが強力な方法です。これは、平均的な量を示すものです。プロダクトバックログ各スプリントによるスクラムチーム開発チームが追跡を使用して。したがって、アジャイルチームのベロシティを計算するには、イテレーション中に成功裏に提供された機能、ユーザーストーリー、要件、またはバックログ項目の見積もりを単純に合計すればよい。チームは次のようにすべきである：

• 特定の日付までに提供できる範囲を予測する。
• 固定された数の範囲が提供される日付を予測する。
• スプリント内で提供することを約束する範囲を定義する際の限界を理解する。

スクラムベロシティの例

数回のイテレーションを完了する前には、スクラムチームの初期ベロシティを推定するための簡単なガイドラインがありますが、その後はチームはスプリント計画のための検証された歴史的ベロシティ推定手法を使用できます。過去の複数回のスプリントに基づいて、ベロシティの推定値は通常安定し、スクラムプロジェクトの短期的および長期的な計画の正確性を向上させるより信頼性の高い基盤を提供します。

ベロシティは、チームが1回のスプリントで完了できる作業量を測定するものであり、スクラムにおける重要な指標です。スプリント終了時に、すべての完全に完了したユーザーストーリーのポイントを合計して計算されます。部分的に完了または未完了のストーリーのポイントは計算に含めないでください。

ステップ1 – 最初のイテレーション（スプリント）のベロシティを計算する

各イテレーションの終了時に、チームはそのイテレーション中に完了したユーザーストーリーに関連する作業見積もりを合計します。この合計値をベロシティと呼びます。

アジャイルチームはイテレーションを開始し、ストーリーAとストーリーB（それぞれ2ポイント）とストーリーC（3ポイント）を完了することを計画しています。イテレーション終了時に、ストーリーAとストーリーBは100％完了していますが、ストーリーCは80％しか完了していません。アジャイルチームは通常、完了レベルを2つだけ認識します：0％または100％。したがって、ストーリーCはベロシティに含まれず、このイテレーションのベロシティは4ポイントです。

ステップ2 – ベロシティを使って必要なイテレーション数を推定する

ステップ1でベロシティを理解した後、チームは将来のイテレーションでベロシティが概ね同じままであると仮定して、残りのユーザーストーリーの見積もりに基づいて、プロジェクトを完了するまでにかかる時間を計算（または修正）できます。これは、正確な予測であるとは限りませんが、通常は非常に正確な予測です。

残りのユーザーストーリーが合計40ポイントを表すと仮定すると、チームの残りの作業に対する予測は10イテレーションです。

スクラムにおけるベロシティとストーリーポイントの関係

ストーリーポイントストーリーポイントは、サイズや複雑さを測定するために使用されます——実質的に、タスクを完了するのにどれくらいの時間がかかるかを示します。ストーリーポイントは、ユーザーストーリーを完了するのに必要な時間の相対的な尺度です。この概念はXPから借用されています。ストーリーポイントは、完了にかかる時間を約束するのではなく、ストーリーの難易度を評価するために使用されます。これにより、チームの規模やタスクの種類に関係なく、ストーリーポイントを使用できます。

速度とストーリーポイントをどのように関連付けるか？

1. チームはしばしば「速度」を生産性の指標として使い、外部の人々にスクラムチームの作業速度を正確に伝える。
2. ストーリーポイントの見積もりがプロジェクト全体を通して一貫している場合、速度を表すためにストーリーポイントを使用するのは理にかなっている。
3. チーム内だけでなく、チーム間、さらには会社全体にわたって一貫性が保たれている場合、生産性の測定やチーム間のパフォーマンス比較が可能になる。
4. ストーリーポイントの値が安定している場合、リリース計画の基準として使用できる。後で可能なスケジュールを評価できる。

ユーザー・ストーリーにストーリーポイントをどのように割り当てるか？

ストーリーポイントは相対的な単位である。チームが最初に取るべきステップは、あるストーリーを基準として定義し、他のストーリーをこの基準に対して推定できるようにすることである。文献によると、バックログ内の最も単純なストーリーを特定し、1ストーリーポイントを割り当て、そのストーリーを基準として他のストーリーを推定するべきである。

ストーリーポイントの推定に使用されるスケールは2種類ある：

• 線形スケール (1, 2, 3, 4, 5, 6, 7, …)
• フィボナッチ数列 (0.5, 1, 2, 3, 5, 8, 13, …)

チームが熟知しており、完了にかかる時間を把握している最初のユーザー・ストーリーを推定するのが良い。次に次のユーザー・ストーリーを推定する。チームが基準ストーリーより時間がかかると判断した場合、基準の左に配置する。次に別のユーザー・ストーリーを推定する。チームが基準より時間はかかるが、2番目のストーリーよりは短いと判断した場合、基準と2番目のストーリーの間に配置する。この例では、ストーリー推定にフィボナッチ数列を使用する：

ユーザー・ストーリー ストーリーポイント

速度をより正確に推定するには？

スクラムでは、速度はチームが製品バックログを完了するのにどれくらいの時間がかかるかを理解するのに役立つ。しかし、通常は数回のスプリントを経て、チームがより安定した速度を見つける。チームの速度をより正確に推定するには、過去の追跡記録を活用できる。これにより、スプリント内でチームが完了できるストーリー数をより正確に予測できる。予測の目的で、過去3回または4回のスプリントの速度の平均を使用すべきである。

新しいスクラムチームが最初のスプリントで41ストーリーポイントを完了すると予定していると仮定する。実際に完了したのは38ストーリーポイントで、6ストーリーポイントを次のスプリントに持ち越した。したがって、彼らの速度は38である（以下に示す）。

スクラムの速度

過去のスプリント追跡に基づく平均速度

前述したように、チームは部分的に完了した作業を速度に含めてはならない。完了とマークされたユーザー・ストーリーのみがカウントされ、たとえ作業のわずかな部分が残っていても同様である。

1回のスプリントに基づく速度は、予測のための信頼性の高い指標ではない。（しかし、チームが1回のスプリントでどれだけの作業をコミットできるかを理解するのに役立つ。）さらにスプリントを経て進捗を追跡しよう。

現在、新しいチームはスプリント1からスプリント4まで開発を継続している。各スプリントで完了したストーリーポイントは：38、29、38、39。4回のスプリント後の平均速度は36である（以下に示す）。

スプリントごとのスクラムの速度

4回のスプリントに基づくこの平均は、1回のスプリント後のスナップショットよりもはるかに有用である。バックログにすでにユーザー・ストーリーの見積もりがあると仮定すれば、この速度を予測に使用できる。チームがすべての作業をどれだけの速さで完了するかを予測できる。次のリリースでどの機能を提供できるかについて、情報に基づいた推測が可能になる。

速度チャート

スクラムチームが複数のスプリントを完了した場合、チームは速度レポートを使ってリリース日および製品完了日を予測し、将来のプロジェクトをより良く計画できる。レポートに示された過去のスプリントの速度に基づいて、以下のことが可能になる：

• 各スプリントでチームが完了した作業量を追跡する。
• チーム構成とスプリント期間が変化しない場合、将来のスプリントでチームが処理できるバックログ作業量を推定する。

上記の例に基づき、速度チャートはスクラムチームが4回のスプリントで完了した作業量を示している：

スクラム速度チャート