スクラムでは、見積とトラッキングは区別されます。見積は、一般的にバックログの主要項目 (PBI、通常はストーリー) に対して行われるもので、バックログの各部分を達成するのにかかる時間を算定するのに使用されます。トラッキングとは、スプリント内のすべてのストーリーが間違いなく達成されるように、スプリントの進捗状況をモニタリングすることを意味します。

トラッキングは、多くの場合、ストーリーをタスクに分割してスプリント計画時に時間見積を適用した後、スプリント中にバーンダウンで残余時間をモニタリングすることによって実行されます。

従来の開発環境では、見積は次のように行われます。

1. チームは「工数」で項目の見積を出し、その工数は精度が高いものと想定されます。
2. 次に、チームはプロジェクトのバックログの工数合計を計算します。
3. その後、工数合計をチームの人数と 1 週間の工数で除算します。これがプロジェクトの予測日付になります。

このような見積は、以下のことを考慮に入れていないため、多くの場合、精度が低くなります。

• チームの本質的な見積特性。つまり、過大見積または過小見積が考慮されません。
• 項目に割り振られた工数途中での予期しない中断
• チームメンバー自身の長期的なパフォーマンス

見積の精度が下がってくると、チームは「無理やり」見積の精度を上げようとして時間と労力を注ぎ込みます。このため、工数をもとにした方法は、不可能でないとしても、困難です。

スクラムの世界では、チームは見積の精度を高めようとはしません。その代わりに、「信頼できるベロシティ」を実現することを目指します。

ベロシティは、チームがスプリントごとに平均して完了する見積単位数の尺度です。最初の数スプリントを完了すると、ほとんどのチームはかなり安定したベロシティを実現します。ベロシティとバックログの PBI に対する見積をもってすれば、チームはバックログの各部分を完了するために要する時間をより正確に予測できます。

重要なことは、スプリントごとに合理的な予測ができる限り、見積単位は問題ではないということです。たとえば、チームは「理想時間」の見積を採用できますが、その時間を経過時間と関連付ける必要もなく、そのように期待されるわけでもありません。あるチームが各スプリントで 120 時間の「工数」をこなす能力を持ちながら、ベロシティが 60 時間であるとしても、それは問題ではありません。なぜなら、そうした差の有無にかかわらず、 60 時間というベロシティは、バックログの各部分を完了するために要するスプリント数の見積に使用でき、したがって経過時間の見積に使用できるからです。

すると、多くの人は「残りの 60 時間」はどうなったのかと考え、チームの生産性に何か問題があるかのように言い始めます。しかし、通常、生産性とは何の関係もありません。チームの自然な行動傾向 (たとえば、過大または過小見積傾向) や組織の経費などを考慮に入れると、見積は、項目の達成がどれほど難しいかというチームの見方を示しているにすぎません。計画の観点からすると、重要なのはベロシティだけです。 

単位は時間に無関係という理由から、現在ほとんどのチームは見積単位にストーリーポイントを選択しています。ストーリーポイントは、１つのストーリーの複雑さを他のストーリーと比較して測定する任意の数です。実質的に、ストーリーポイントが時間との精神的なつながりを断っていることは明らかです。

チームのベロシティを安定した状態にするためには、チームは同程度の精度でバックログの各項目を見積もる必要があります。当たり前のことを繰り返し述べることになりますが、ベロシティが目指しているのは、特によく理解されているわけではないストーリーのバックログを見て、それを完了するのにどれだけのスプリントが必要かを理解することです。このことから、バックログにある見積がすべて同程度に不確実であることが求められます。

にわかには受け入れがたいかもしれませんが、いったんチームが各項目に対する見積を出したら、その項目について初期見積が間違っていたと感じさせる新たな情報を発見した場合でも、見積を変更すべきではないという考えがあります。チームが先に進んだ段階で見積を更新する場合、この「新たな情報の発見」は定期的に発生することとなります。その結果、バックログには高精度の項目がある一方で、大半はそれほど精度が高くないという状況をもたらします。高精度な見積の占める割合が高いスプリントと、高精度な見積の占める割合が低いスプリントとでは、完了させる単位数に違いが出るため、このような状況はベロシティに悪影響を与えます。その結果、ベロシティはその主な目的、つまり、バックログ内のそれほどよく理解されていないストーリーの 1 セットを完了するために要するスプリント数を見積もるという目的に使用できなくなります。したがって、はるか先の将来の時点で、あまりよく理解されていない作業を特定の単位数完了する能力をチームのベロシティで現実的に表すためには、初期見積を使用することが重要なのです。

次のようなシナリオを考えてみましょう。

• 課題 X に対する初期見積は 5 日です。
• 次のスプリントが計画される前に、チームは初期見積が非常に楽観的で、実際には課題の達成に 15 日かかると気付きます。 

実際には 15 日かかる作業なのに、所要期間 5 日の作業と想定して次のスプリントに組み込むことになるので、初期見積を使用するのはスプリントの成功を危うくすると異議を唱える人も出てくるでしょう。

しかし、5 日というような精度の低い見積を出すことは珍しくありません。実際、見積には常に間違いがあるものです (ごくわずかの誤りもあれば、大幅な誤りもあります)。多くの場合、こうした見積の誤りはスプリントの前ではなく、むしろスプリントが開始された後に発見されます。チームがバックログ全体で同じ方法で見積もってさえいれば、時間がたつうちにうまく機能するようになります。たとえば、常に過小評価している場合、 4 人のチームで 10 日と見積もったスプリントに対し、実際にコミットできるのはチームの見積単位の 20 日間のみと気付くことになるかもしれません。安定したベロシティを確立していれば、これは問題になりません。計画の観点からは、このままでも今後のスプリントでどれだけの作業を処理できるか確実に見積もることができるからです。

スプリントを開始する時が来ると、チームは現実的に完了可能なバックログの項目に対する指標として、ベロシティを使用できます。このベロシティは、チームが以前無事に完了させた項目数をもとにしています。しかし、既に完了している可能性のある作業に関する情報、あるいは作業の特定の項目の難易度に関する情報が初期見積に含まれていない場合、ベロシティの正当性に疑問を投げかける人たちもいるかもしれません。

例として、次のシナリオを検討してみましょう。 

• ある課題に対する初期見積は 10 日です。
• チームは、現在のスプリントでこの課題に 5 日かけています。
• チームは、プロジェクト内の別の場所にひどいバグを発見し、課題 X を予定通り完了させるよりも、そのバグを現在のスプリントで修正することのほうがはるかに重要だと判断します。
• そのスプリントが完了し、課題はバックログに戻されます。

次のスプリントで、チームは課題の見積を 5 日に更新して、その前提で課題をスプリントに組み込むかどうか判断したくなります。これは、チームが課題の初期見積である 10 日間を使用した場合、次のスプリントでは十分な作業が組み込まれない可能性があることを意味します。しかし、前の課題が完了しなかったのは、計画外の​​作業によるものです。今後、おそらく次のスプリントであっても、これが再び起こらないと仮定するのは現実的ではありません。したがって、そのような確実性がない状況では 10 日という見積は現実的な数字です。結果として、計画に含まれていない作業が発生した場合のコストは、最終的に初期見積に計上されることになります。次のスプリントの作業量が不十分であると判明した場合でも、チームはそのスプリントに作業をさらに組み込むことで修正できます。

同じ例で、この課題がスプリントの唯一の課題であり、次回のスプリントでも唯一の課題であると考えてみましょう。課題が 2 回目のスプリントで完了し、残余見積を使用する場合、ベロシティは (0 日 + 5 日) / 2 = 2.5 日となります。しかし、チームは明らかに今後のスプリントでこれよりも多くの作業を完了できます。初期見積を使用する場合は、ベロシティは (0 日 + 10 日) / 2 = 5 日となります。初期見積を使用することによって、予定外の作業が生じた場合、スプリントによっては 10 日をコミットできないこともあるという事実を説明できます。また、現実的に、計画外の作業がすべてのスプリントで起こるわけではないという事実の説明にもなります。

多くのチームでは、スプリントを開始する直前にストーリーをサブタスクに分割し、ストーリーをトラッキングできるようにしています。このことから浮かび上がってくるのが、スプリントでどの課題に取り組むべきか決定する方法として（そして潜在的にベロシティ用としても）、サブタスクを見積もった合計を使用する可能性です。 

先に述べたように、トラッキングは見積やベロシティとはまったく別のプロセスです。サブタスクに適用される見積は、最初にストーリーに適用された見積よりも明らかに高精度です。ベロシティにサブタスクの見積を使用すると、高精度と低精度の両方の見積のベロシティが混在することになり、ストーリーの見積が全て低精度のバックログでは、ベロシティを使用してしっかりとした見通しを立てることができなくなります。

さらに、バックログの上部にある項目のみがタスクに分割された可能性があるため、タスクの見積をベロシティに使用した場合、ベロシティの値によって予測できるのは、タスクに分割された直近のストーリーまでのバックログを完了するために要する時間のみとなります。

また、サブタスクのロールアップを使用してスプリントの取り組みを決定することも危険です。ベロシティの値とは異なり、予定外の仕事や中断に要する経費を考慮に入れていないからです。

時間見積から脱却して、ストーリーポイントという方法を採用する業界のリーダーが増加しています。これは道理です。というのも、スプリントでは、主に次のような疑問に答えを出す必要があるからです。

• このスプリントの完了までに、現実的にどれだけの作業量をコミットできるか。
• バックログのこの部分を完了するためにどのぐらいの期間が必要か。

初期見積をもとにしたストーリーポイントによる方法であれば、チームが時間で見積もるように求められた時に感じる「精度」に関する不安を抱くこともなく、こうした質問に対する答えを出すことができます。

The Jira Software team itself uses the approach described in this article, and has established a reliable velocity that we use to plan work months in advance — even when new work has been encountered during those months. We recommend this approach because while it is sometimes counter-intuitive, it is also powerful, fast, and simple. 

All of that said, one of the key precepts of agile is finding the way that works for you. So Jira Software does support the alternatives described above, including the use of remaining estimates for sprint commitment, hours for estimation, and hour estimates on sub-tasks.