★★★スプリント計画の段階で、一部の新規バックログ・アイテムについて優先順位付けがなされましたが、見積りは手付かず。見積りしてもらうのに適切な対応は？「最初に出した見積もりをチームに渡してそれを修正してもらう」「新しいエピックを定義する」「受入基準を「Ready（準備完了）の定義（DoR）」に加えたあとに見積りを作成する」「類似テストをもとに類推見積りを利用」

→受入基準を「Ready（準備完了）の定義（DoR）」に加えたあとに見積りを作成する

すべての作業が含まれるようにするため、見積り作成前に、インパクトを受ける全アイテムのDoRにおいて具体的な受入基準を定義して確認する必要があります。

見積もり品質の向上: 見積もりは、そのアイテムが何であるか、どのような価値を提供するか、そして「完了」と見なされるために何が必要かについて明確な理解がある場合にのみ正確に行えます。受入基準は、この「完了」の定義を明確にし、チームがより現実的な見積もりを行うための基盤を提供します。

「Readyの定義」の重要性: アジャイル開発において「Readyの定義 (Definition of Ready)」は、バックログアイテムがスプリントに取り込まれる準備が整っているかどうかを判断するための基準です。これには、アイテムが明確に記述され、理解され、そして見積もり可能であることが含まれます。受入基準はこのDoRの一部として機能することがよくあります。

手戻りの防止: 不明確なアイテムを見積もると、後になって要件が変更されたり、見積もりが大きくずれたりする可能性が高まります。これはスプリントの計画を混乱させ、手戻りを引き起こす原因となります。受入基準を明確にすることで、このようなリスクを軽減できます。

エピックは、大きな開発項目を管理するためのもの。より大きな機能やユーザーの要求を表すものです。新規のバックログアイテムが見積もりされていないからといって、すぐに新しいエピックを定義する必要はありません。むしろ、既存のエピックに属する個別のストーリーである可能性も考えられます。

解説

スプリント計画で見積りができないのは、バックログ・アイテムが十分に明確ではないためです。アジャイルでは、バックログ・アイテムが「DoR（準備完了の定義）」を満たして初めて、チームは正しく見積りできます。特に 受入基準 が曖昧だと、作業範囲・完成条件が不明確なまま見積ることになり、不正確でリスクが高い。
よって、まず 受入基準を明確にし DoR に追加 → その後に見積り が正しい流れです。

その他の選択肢が誤りである理由

「最初に出した見積もりをチームに渡してそれを修正してもらう」
外部が出した見積もりをベースにするのは チームの自主性と責任を損なう。見積りはあくまで 開発チームが主体で行う。
「新しいエピックを定義する」
見積りができない原因は粒度や基準の不明確さであり、必ずしもエピック定義が必要なわけではない。むしろさらに大きな単位にまとめるのは逆効果。
「類似テストをもとに類推見積りを利用」
推測に頼るのではなく、まず 受入基準を定義してDoRを満たすことが先決。精度の高い見積りにつながらない。