チームが製品を開発している場合でもプロジェクトを開発している場合でも、「いつ完成させられるか?」あるいは「ある時点でどれだけ提供できるか?」という問いに答える必要があります。従来の開発モデルと同様に、プロジェクトを開始する前に作業量を推定する必要があります。
アジャイル見積もりには以下の3つの特徴があります:
チームによる共同見積もり
においてスクラム開発において、チームは責任を共有し、それぞれのスプリントに向けて共同で取り組みます。そのため、アジャイルチームは作業量を推定するために共同見積もりの手法を使用します。共同見積もりは通常、チームが collectively で見積もりゲームを行うためのツールとしてプランニングポーカーを使用します。プランニングポーカーは、アジャイル開発における作業量を推定する上で最も効果的で魅力的な手法の一つとされています。これはフィボナッチ数列に似た数値のセットで構成されています:0、0.5、1、2、3、5、8、20、40、?、∞。各デッキにはこれらのフィボナッチ数値の4セットが含まれており、最大4人のチームメンバーが使用できるように設計されています。
グループ見積もりと個人見積もりの正確性
ソフトウェアプロジェクト実験における個人とグループの作業量推定の正確性に関する調査では、同じ会社の20人のソフトウェア専門家が、同じソフトウェアプロジェクトの実装に必要な作業量を個別に推定しました。参加者は異なる背景と役割を持っており、そのソフトウェアプロジェクトは以前に実装済みでした。その後、彼らは5つのチームに分かれました。各チームは知識を共有し、一つの見積もりに合意するための議論を行いました。
結果:グループによる議論に基づく見積もりは、個人による見積もりよりも正確でした。
プランニングポーカーの遊び方のステップ
- 各チームメンバーは、0、0.5、1、2、3、5、8、13、20、40、?、∞ の12枚のカードからなるセットを受け取ります。
- そしてプロダクトオーナーは、ユーザー ストーリーまたは機能の説明をチームに読み上げます。
- チームメンバーは機能について議論し、必要に応じてプロダクトオーナーに質問を行います。
- 議論の後、各メンバーは自分の見積もりを表すカードを選択し、同時に公開します。
- 見積もりが著しく異なる場合、チームは次のように議論します:合意できますか?どのような要因を無視しましたか?最高または最低の見積もりを出した人は、次の投票ラウンドの前に自分の考えを説明する必要があります。
- 議論の後、合意に達するまで、チームはもう一度ラウンドを繰り返すことがあります。
- ステップ2に戻り、次のバックログ項目の見積もりを開始します。
時間ではなくサイズを推定する — 絶対推定ではなく相対推定を使用する
見積もりとは単なる経験則に基づいた推測にすぎません。利用可能なすべての知識と経験を活用して、どれくらいの時間がかかるかを推定します。新しい作業項目を孤立して評価するのではなく、過去に完了した項目と比較してはいかがでしょうか?人間は絶対的なサイズを推測するよりも、類似したサイズのものと関係づけるのが得意です。
たとえば:これは非常に小さな項目に近いですか?それとも中程度の規模のプロジェクトに近いですか?それとも先月完了したプロジェクトのように本当に大きなものでしょうか?相対推定は見積もりにかける時間の削減だけでなく、正確性を著しく向上させます。
私たちの脳は絶対推定が得意ではない — 新しいものを推定する際、私たちは常に既に知っているものと関連づけています。

ストーリーポイントの見積もり
速度の見積もり — スプリントごとのチームの速度を記録し、平均化する
チームの速度はスプリント内で実際に完了するストーリーポイントのスクラムチーム実際にスプリント内で完了する数です。チームの速度は、チームがどれだけ速く作業を進めるかを示します。新しいプロジェクトやチーム(過去の速度記録がない場合)では、初期の速度を測定・設定するために1〜2回のスプリントを実施できます。スプリント実行中に、将来の計画のために各スプリントごとにチームの速度を記録します。

ユーザーストーリーの速度の見積もり
私たちは、プロダクトバックログにあるストーリーポイントの合計数を見積もります。スプリントごとの平均速度がわかれば、プロジェクトを完了するために必要なスプリント数を計算でき、その結果としてプロジェクトの期間を推定できます。以下の図に示す通りです。

スクラムプロジェクトの期間見積もり