レポートMarketplace製品アプリケーション請求とライセンス情報よくある質問ログアウトアカウントにログインサポートにお問い合わせください。コミュニティをご利用ください。コミュニティに質問はじめる前にバックログのストーリーを見積もることで、バックログの特定部分の達成に要する期間を予測することができます。メインパスとして実装してきたベストプラクティスに関するものであることにご注意ください。この方法が自分のチームにあまり適していないと感じた場合は、採用しなくてもかまいません。これはスクラムボードのみに当てはまります。課題を見積もるスプリントを開始する前に、課題の初期見積を入力する必要があります。スプリントの間、課題に取り組む過程で必要に応じて残余見積を調整する必要がある場合もあります。初期見積を入力するには、各課題に対して以下を実行します。初期見積を設定する課題をクリックします。フィールドに見積を入力します。見積統計によって異なります。「見積とトラッキングの設定」を参照してください。残余見積を調整するには:希望のボードのアクティブなスプリントへ移動します。残余見積を調整したい課題をクリックします。課題詳細ビューで、残余フィールドに見積もりを入力します。トラッキング統計によって異なります。「見積とトラッキングの設定」を参照してください。課題を見積もる場合に考慮すべき概念を以下に示します。見積はトラッキングではないスクラムでは、見積とトラッキングは区別されます。対して行われるもので、バックログの各部分を達成するのにかかる時間を算定するのに使用されます。トラッキングとは、スプリント内のすべてのストーリーが間違いなく達成されるように、スプリントの進捗状況をモニタリングすることを意味します。トラッキングは、多くの場合、ストーリーをタスクに分割してスプリント計画時に時間見積を適用した後、スプリント中にバーンダウンで残余時間をモニタリングすることによって実行されます。従来の開発環境では、見積は次のように行われます。チームは「工数」で項目の見積を出し、その工数は精度が高いものと想定されます。次に、チームはプロジェクトのバックログの工数合計を計算します。週間の工数で除算します。これがプロジェクトの予測日付になります。このような見積は、以下のことを考慮に入れていないため、多くの場合、精度が低くなります。チームの本質的な見積特性。過大見積または過小見積が考慮されません。項目に割り振られた工数途中での予期しない中断チームメンバー自身の長期的なパフォーマンス見積の精度が下がってくると、チームは「無理やり」見積の精度を上げようとして時間と労力を注ぎ込みます。このため、工数をもとにした方法は、不可能でないとしても、困難です。スクラムにおける見積はベロシティがすべてスクラムの世界では、チームは見積の精度を高めようとはしません。その代わりに、「信頼できるベロシティ」を実現することを目指します。ベロシティは、チームがスプリントごとに平均して完了する見積単位数の尺度です。最初の数スプリントを完了すると、ほとんどのチームはかなり安定したベロシティを実現します。対する見積をもってすれば、チームはバックログの各部分を完了するために要する時間をより正確に予測できます。重要なことは、スプリントごとに合理的な予測ができる限り、見積単位は問題ではないということです。チームは「理想時間」の見積を採用できますが、その時間を経過時間と関連付ける必要もなく、そのように期待されるわけでもありません。時間であるとしても、それは問題ではありません。時間というベロシティは、バックログの各部分を完了するために要するスプリント数の見積に使用でき、したがって経過時間の見積に使用できるからです。時間」はどうなったのかと考え、チームの生産性に何か問題があるかのように言い始めます。通常、生産性とは何の関係もありません。組織の経費などを考慮に入れると、見積は、項目の達成がどれほど難しいかというチームの見方を示しているにすぎません。計画の観点からすると、重要なのはベロシティだけです。単位は時間に無関係という理由から、現在ほとんどのチームは見積単位にストーリーポイントを選択しています。ストーリーポイントは、1つのストーリーの複雑さを他のストーリーと比較して測定する任意の数です。実質的に、ストーリーポイントが時間との精神的なつながりを断っていることは明らかです。精度の低い見積であっても、どれも同様に精度が低い限り、問題はないチームのベロシティを安定した状態にするためには、チームは同程度の精度でバックログの各項目を見積もる必要があります。当たり前のことを繰り返し述べることになりますが、ベロシティが目指しているのは、特によく理解されているわけではないストーリーのバックログを見て、それを完了するのにどれだけのスプリントが必要かを理解することです。このことから、バックログにある見積がすべて同程度に不確実であることが求められます。にわかには受け入れがたいかもしれませんが、いったんチームが各項目に対する見積を出したら、その項目について初期見積が間違っていたと感じさせる新たな情報を発見した場合でも、見積を変更すべきではないという考えがあります。チームが先に進んだ段階で見積を更新する場合、この「新たな情報の発見」は定期的に発生することとなります。その結果、バックログには高精度の項目がある一方で、大半はそれほど精度が高くないという状況をもたらします。高精度な見積の占める割合が高いスプリントと、高精度な見積の占める割合が低いスプリントとでは、完了させる単位数に違いが出るため、このような状況はベロシティに悪影響を与えます。セットを完了するために要するスプリント数を見積もるという目的に使用できなくなります。したがって、はるか先の将来の時点で、あまりよく理解されていない作業を特定の単位数完了する能力をチームのベロシティで現実的に表すためには、初期見積を使用することが重要なのです。日かかると気付きます。日の作業と想定して次のスプリントに組み込むことになるので、初期見積を使用するのはスプリントの成功を危うくすると異議を唱える人も出てくるでしょう。日というような精度の低い見積を出すことは珍しくありません。(ごくわずかの誤りもあれば、大幅な誤りもあります)。多くの場合、こうした見積の誤りはスプリントの前ではなく、むしろスプリントが開始された後に発見されます。チームがバックログ全体で同じ方法で見積もってさえいれば、時間がたつうちにうまく機能するようになります。日間のみと気付くことになるかもしれません。安定したベロシティを確立していれば、これは問題になりません。計画の観点からは、このままでも今後のスプリントでどれだけの作業を処理できるか確実に見積もることができるからです。それはスプリントのコミットメントを損なうのでは?スプリントを開始する時が来ると、チームは現実的に完了可能なバックログの項目に対する指標として、ベロシティを使用できます。このベロシティは、チームが以前無事に完了させた項目数をもとにしています。完了している可能性のある作業に関する情報、あるいは作業の特定の項目の難易度に関する情報が初期見積に含まれていない場合、ベロシティの正当性に疑問を投げかける人たちもいるかもしれません。例として、次のシナリオを検討してみましょう。