課題の見積もり

はじめる前に

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

このページの内容は スクラム ボードにのみ適用されます。

課題を見積もる

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

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

  1. Select an issue and enter an estimate in the Story points or Original estimate field (depending on the estimation statistic you set).

  1. 選択した課題: 課題を選択すると、右側に詳細が表示されます。
  2. 見積もりフィールド: 見積もり統計に応じて、ストーリー ポイントまたは時間見積もりを入力します。


tip/resting Created with Sketch.

We're rolling out a new issue view, with a consistent appearance across Jira and one screen to view and edit. It looks a little different and some procedures have changed slightly, so take a look at Changes to issues in the new issue view to see what's changed. To turn the new issue view on or off in Jira Software and Jira Core for now, head to Your profile and settings () > Personal settings and toggle the switch for the New Jira issue view.

新しい課題ビューは、すべてのビジネス ボードおよび次世代ソフトウェア プロジェクトで常に有効化されています。

アバターをクリックしても [個人設定] オプションが表示されない場合、新しい課題ビューのオン / オフを切り替えるスイッチは [プロファイル] に表示されます。

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

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

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

tip/resting Created with Sketch.

課題の作業ログを表示または編集するには、課題を開き、[コメント] を選択してから、[作業ログ] を選択します。


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

残余見積および消費時間を有効化したときのサブタスクの動作 残余見積および消費時間を無効化したときのサブタスクの動作

既にアクティブなスプリント内の課題にサブタスクを追加すると、サブタスクはスコープ変更として処理されます。

スコープ変更は、バーンダウン グラフにも表示されるようになりました。

既にアクティブなスプリント内にある課題にサブタスクを追加すると、サブタスクはスコープ変更としても処理されます。

ただし、スコープ変更は、サブタスクのバーンダウン チャートには反映されません。

サブタスクの見積時間は親タスクにまとめられます。

つまり、親タスクはサブタスクのすべての残余見積の合計を持ちます。

見積時間はサブタスク全体および親タスク自体で個別にトラッキングされます。

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

見積もりに関する概念

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

にわかには受け入れがたいかもしれませんが、いったんチームが各項目に対する見積を出したら、その項目について初期見積が間違っていたと感じさせる新たな情報を発見した場合でも、見積を変更すべきではないという考えがあります。チームが先に進んだ段階で見積を更新する場合、この「新たな情報の発見」は定期的に発生することとなります。その結果、バックログには高精度の項目がある一方で、大半はそれほど精度が高くないという状況をもたらします。高精度な見積の占める割合が高いスプリントと、高精度な見積の占める割合が低いスプリントとでは、完了させる単位数に違いが出るため、このような状況はベロシティに悪影響を与えます。その結果、ベロシティはその主な目的、つまり、バックログ内のそれほどよく理解されていないストーリーの 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 日をコミットできないこともあるという事実を説明できます。また、現実的に、計画外の作業がすべてのスプリントで起こるわけではないという事実の説明にもなります。

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

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

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

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

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

ストーリーポイントが強く推奨されているが、チームのどの作業に適用するのか

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

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

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

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

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

最終更新日 2019 年 7 月 9 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.