課題の見積もり

Screenshot: Estimating an issue in Plan mode

The type of units used by the 'Estimate' field (e.g. hours) is affected by your Estimation Statistic — see Configuring Estimation and Tracking.

残余見積を入力する

課題に取り組む過程で、残余見積を次の手順で調整します。

1. 上部ナビゲーションバーで Agile リンクの下矢印をクリックし、表示されるドロップダウンメニューから目的のボードを選択します。
2. Click Work to go to Work mode.
3. カードの右側の残余フィールドをクリックし、各課題の残余見積を入力します。 

Screenshot: Estimating an issue in Work mode

The type of units used by the 'Remaining' field (e.g. hours) is affected by your Tracking Statistic — see Configuring Estimation and Tracking.

見積について

Note that this discussion refers to the best practices we've implemented as the main path in GreenHopper — you can choose not to use this approach if you feel it's really not suitable. 

見積は、トラッキングとは別もの

スクラムでは、見積とトラッキングは区別されます。見積は、主としてバックログの主要項目（ PBI 、通常ストーリー）に対して行われるもので、バックログの各部分を達成するのにかかる時間を算定するのに使用されます。トラッキングは、スプリント内のすべてのストーリーが間違いなく達成されるように、スプリントの進捗状況をモニタリングすることをいいます。トラッキングは、多くの場合、ストーリーをタスクに分割し、プランミーティングで見積時間を割り当てた後、スプリント中にバーンダウンで残余時間をモニタリングすることによって実行されます。 

見積は、ベロシティがすべて

PBI（プライマリバックログアイテム）について見積を出す主な目的は、その見積情報を使って、バックログの各部分を達成するのにかかる時間を算定することです。

従来の開発環境では、チームは「工数」で項目の見積を出し、その工数は精度が高いものと想定されます。そして、プロジェクトのバックログで工数を合計して、チームの人数と週時間数で割り、完了予想日を割り出します。もちろん、こうした見積は、多くの場合、見積の際に（過大または過小な見積に傾く）チームが持つ自然な傾向や、予期しない中断、作業期間中のチームのパフォーマンスの改善などを考慮に入れていないため、非常に精度が低いことが判明しました。見積の精度の低さに加えて、見積の精度を「何とかして」高くしようとして消費した時間コストの大きさが影響し、「工数」によるアプローチは、不可能ではないにしても、効果を発揮するのが難しくなっています。 

そのため、スクラムの世界では、ほとんどのチームは見積の精度を高めようとしていません。その代わりに、信頼できるベロシティを実現することを目指しています。ベロシティは、チームがスプリントごとに平均して完了するユニット数を見積もる尺度です。最初の数スプリントを完了すると、ほとんどのチームはかなり安定したベロシティを実現します。ベロシティとバックログの 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 GreenHopper team itself uses the approach described in this article and has established a reliable velocity that we have used to plan months in advance, even when new work has been encountered during those months. 

私たちはこの方法を推奨します。それは、この方法が直感に反していることがある一方で、パワフルで高速かつ簡単だからです。 

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