はじめる前に

Estimating stories in your backlog helps you predict how long it would take you to deliver certain portions of the backlog. Note that this discussion refers to the best practices we've implemented as the main path in Jira Software. You can choose not to use this approach if you feel it's not suitable for your team.

課題を見積もる

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

見積もりを入力する方法:

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

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

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

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

1. スクラム ボードのアクティブ スプリントに移動します。
2. Select an issue and choose ••• > Log work (or click on the time tracking field).
3. 消費時間と残余時間を入力し、[保存] をクリックします。

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

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

見積もりに関する概念

Here are some concepts to consider when estimating issues in 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 回目のスプリントで完了し、残余見積を使用する場合、ベロシティは (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.