Estimate a work item

はじめる前に

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

Estimate a work item

Before a sprint starts, you need to enter estimates for your work items.

見積もりを入力する方法

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

2. Select a work item and enter an estimate in the Story points or Original estimate field (depending on the estimation statistic you set).

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

As you work on work items during the sprint, you can log time and adjust the remaining time estimate if necessary. Logging time provides valuable info you can use for reporting in Jira.

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

2. Select a work item and choose  > Log work (or click on the time tracking field).

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

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

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

見積もりに関する概念

Here are some concepts to consider when estimating work items in Jira Software.

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

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

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

従来の開発環境で行われる見積方法

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

1. チームは "工数" で項目の見積もりを出し、その工数は精度が高いものと想定されます。

2. 次に、チームはプロジェクトのバックログの工数合計を計算します。

3. その後、工数合計をチームの人数と 1 週間の工数で除算します。これがプロジェクトの予測日付になります。

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

• チームの本質的な見積特性 (つまり、過大見積または過小見積が考慮されていない)

• 項目に割り振られた工数途中での予期しない中断

• チーム メンバーの長期的なパフォーマンス

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

スクラムにおける見積もりはベロシティがすべて

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

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

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

それでは残りの 60 時間はどうなったのか、チームの生産性に問題があるのではないのか、と思うかもしれません。しかし一般的に、これは生産性とは無関係です。見積もりは、チームの自然な行動 (過大評価や過小評価など) や組織のオーバーヘッドなどを考慮しながら予想した、アイテムの難易度にすぎません。計画策定の観点から言えば、大事なのはベロシティのみです。 

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

精度の低い見積であっても、どれも同様に精度が低い限り、問題はない

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

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

チームが見積りを誤っていたことに気づいた場合はどうすればよいですか?

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

• Work item X has an Original Estimate of 5 days.

• Before the next sprint is planned, the team realizes that the Original Estimate was too optimistic, and that the work item actually takes 15 days. 

15 日かかる作業を所要期間 5 日の作業と想定して次のスプリントに組み込むことになるため、初期見積もりを使用するのはスプリントの成功を危うくするとも考えられます。

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

それはスプリントのコミットメントを損なうのではないでしょうか?

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

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

• A work item has an Original Estimate of 10 days.

• The team works 5 days on the work item in the current sprint.

• The team discovers a bad bug somewhere else in the project, and they decide that fixing that bug in the current sprint is far more important than completing work item X as planned.

• The sprint gets finished, and the work item returns to the backlog.

In the next sprint, the team would be tempted to update the estimate for the work item to 5 days, and use that to make their decision whether or not to include it in the sprint. The implication is that they might not include enough work in the next sprint if they used the work item’s Original Estimate of 10 days. However, the reason that the task was not completed previously is because of unplanned work — and it's unrealistic to assume that this won't happen again in the future, perhaps even in the next sprint. Thus, the 10-day estimate is a realistic number to use in the absence of certainty. As a result, the cost of the unplanned work that may happen is eventually accounted for in the Original Estimate. Even if the work does turn out to be insufficient for the next sprint, the team will correct that by dragging more work into the sprint.

In the same example, consider if this were the only work item in that sprint and will be the only work item in the next. If the work item is completed in the second sprint, and we use the remaining estimate, then the velocity will be (0d + 5d) / 2 = 2.5d. However, the team can clearly complete more work than that in future sprints. If we use the Original Estimate, then the velocity will be (0d + 10d) / 2 = 5d. The use of the Original Estimate accounts for the fact that the team cannot commit to 10d in every sprint because unplanned work will likely make that impossible. It also realistically accounts for the fact that unplanned work will not happen in every sprint.

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

Many teams break down stories into subtasks shortly before the sprint begins so they can use the stories for tracking. This raises the possibility of using the sum of the estimates on the subtasks as a way to decide which work items to commit to in the sprint (and potentially for velocity). 

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

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

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

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

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

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

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

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

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

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