課題を見積もる

はじめる前に

バックログでストーリーを見積もることで、バックログの特定部分の提供に要する期間を予測することができます。この内容は、Jira Software のメイン パスとして実装してきたベスト プラクティスに関するものであることにご注意ください。この方法がご自身チームに適していない場合、利用する必要はありません。

課題を見積もる

スプリントを開始する前に課題の見積もりを入力する必要があります。

見積もりを入力する方法

1. スクラム プロジェクトのバックログに移動します。

2. 課題を選択し、[ストーリー ポイント] または [初期見積] フィールド (設定した見積もり統計によって異なります) に見積もりを入力します。

時間の記録と残余見積時間の調整

スプリント中に課題に取り組むときに時間を記録し、必要に応じて残余見積時間を調整することができます。時間を記録すると、Jira でのレポート作成に使用できる便利な情報が得られます。

1. スクラム ボードのアクティブ スプリントに移動します。

2. 課題を選択し、 > [時間の記録] を選択します (または [時間追跡] フィールドをクリックします)。

3. 消費時間と残余時間を入力し [保存] をクリックします。

バーンダウン チャートを使用している場合、サブタスクの動作は、ボードの [残余見積と消費時間] が有効化されているかどうかによって異なることがあります。

詳細については、「バーンダウン チャート」を参照してください。

見積もりに関する概念

Jira Software で課題を見積もる場合に考慮すべき概念を以下に示します。

見積はトラッキングではない

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

サブタスクの見積りをベロシティやスプリントの取り組みにロールアップしない理由

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

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

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

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

ストーリー ポイントが強く推奨されているが、チームに最適な方法をご利用ください

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

• このスプリントの完了までに、現実的にどれだけの作業量をコミットできるか

• バックログのこの部分を完了するためにどのぐらいの期間が必要か

初期見積に基づいたストーリー ポイント手法により、チームは時間で見積もるように求められた時に感じる "精度" に関する不安を抱かず、こうした質問に対する答えを出すことができます。

Jira Software チーム自身がこの記事で説明している方法を使用し、信頼性の高いベロシティを確立しました。何か月も前に作業計画を立てるために、さらに、その計画期間中に新しい作業が発生した時でさえ、このベロシティを活用しています。私たちはこの方法を推奨します。直感と相容れない場合があるとはいえ、パワフルで高速かつ簡単だからです。 

そうは言っても、アジャイルに関する重要な教訓のひとつは、自分にとってうまく行く方法を見つけることです。そのため、Jira Software では、スプリントの取り組みに残余見積を使用することや、見積もりに時間を使うこと、サブタスクを時間で見積もることなど、上に述べたものとは別の選択肢もサポートしています。