スクラム-見積もり

スクラムプロジェクトでは、見積もりはスプリント計画会議中にチーム全体で行われます。見積もりの目的は、スプリントのユーザーストーリーを優先度と、スプリントのタイムボックス中に配信するチームの能力によって検討することです。

プロダクトオーナーは、優先順位が付けられたユーザーストーリーが明確であり、見積もりの対象となることを保証し、それらがプロダクトバックログの先頭に表示されます。

スクラムチーム全体が製品増分の配信を担当するため、製品増分のサイズとそれに必要な労力に基づいて、スプリントのユーザーストーリーを選択するように注意が払われます。

製品の増分のサイズは、ユーザーストーリーポイントの観点から推定されます。サイズが決定されると、過去のデータ、つまり生産性と呼ばれるユーザーストーリーポイントごとの作業量を使用して作業量が推定されます。

スクラム推定手法

ユーザーストーリーのスクラム推定は、各ユーザーストーリーの難易度の観点から行われます。難易度を評価するために、特定のスケールが使用されます。

スクラム推定で使用されるスケールにはいくつかのタイプがあります。以下はいくつかの例です-

数値サイズ（1から10）
Tシャツのサイズ（XS、S、M、L、XL XXL、XXXL）
フィボナッチ数列（1、2、3、5、8、13、21、34など）
犬の品種（チワワ、………、グレートデーン）

推定手法は通常、スクラムチーム全体がスケールの値に精通し、快適になるように選択されます。最も一般的に使用され、最も人気のある手法は、フィボナッチ数列に基づくプランニングポーカーです。

プランニングポーカーテクニック

プランニングポーカー推定手法では、ユーザーストーリーの推定値は、プランニングポーカーをプレイすることによって導き出されます。スクラムチーム全体が関与し、迅速で信頼性の高い見積もりが得られます。

プランニングポーカーはカードのデッキでプレイされます。フィボナッチ数列が使用されているため、カードには1、2、3、5、8、13、21、34などの番号が付いています。これらの番号はストーリーポイントを表しています。各推定量には、カードのデッキがあります。カードの数字は、チームメンバーの1人がカードを持っているときに、すべてのチームメンバーに見えるように十分に大きくする必要があります。

チームメンバーの1人がモデレーターとして選ばれます。モデレーターは、見積もりが行われているユーザーストーリーの説明を読みます。見積もり担当者に質問がある場合は、プロダクトオーナーが回答します。

各見積もり担当者は、自分の見積もりを表すカードを個人的に選択します。すべての推定者が選択を行うまで、カードは表示されません。その際、すべてのチームメンバーがそれぞれの見積もりを確認できるように、すべてのカードが同時に裏返され、保持されます。

最初のラウンドでは、見積もりが異なる可能性が非常に高くなります。高推定量と低推定量は、推定の理由を説明します。すべての議論は理解のみを目的としており、個人的には何も行われないように注意する必要があります。モデレーターは同じことを確認する必要があります。

チームは、ストーリーとその見積もりについて、さらに数分間話し合うことができます。

モデレーターは、特定のストーリーが作成されるときに役立つディスカッションについてメモを取ることができます。話し合いの後、各推定者はカードを再度選択して再推定します。カードは、全員が推定するまで再び非公開にされ、推定されると同時に裏返されます。

見積もりがストーリーに使用できる単一の見積もりに収束するまで、このプロセスを繰り返します。見積もりのラウンド数は、ユーザーストーリーごとに異なる場合があります。

プランニングポーカー見積もりの利点

プランニングポーカーは、3つの見積もり方法を組み合わせています-

Expert Opinion：専門家の意見に基づく見積もりアプローチでは、専門家は何かにかかる時間や大きさを尋ねられます。専門家は、彼または彼女の経験または直感または直感に基づいて見積もりを提供します。

専門家の意見の見積もりは、通常、それほど時間はかからず、いくつかの分析方法と比較してより正確です。

Analogy：アナロジー推定は、ユーザーストーリーの比較を使用します。見積もり中のユーザーストーリーは、以前に実装された同様のユーザーストーリーと比較されます。推定は実証済みのデータに基づいているため、これにより正確な結果が得られます。

Disaggregation：分解の推定は、ユーザーストーリーをより小さく、推定しやすいユーザーストーリーに分割することによって行われます。スプリントに含まれるユーザーストーリーは、通常、開発に2〜5日の範囲です。したがって、より長い時間がかかる可能性のあるユーザーストーリーは、より小さなユースケースに分割する必要があります。このアプローチはまた、比較可能な多くのストーリーがあることを保証します。