INVEST

スクラム、かんばん、 XPなどのアジャイル手法の特徴の1つは、PBIを、労力をかけずに相対的な優先順位を考慮して移動できることです。強く依存しているPBIを見つけた場合は、それらを1つのPBIに結合し、大きなPBIを見つけた場合は、より小さく分割することをお勧めします。

PBIは、チームメンバーによって、ビジネス、市場、技術、その他の種類の要件に応じて、書き換えたり破棄したりすることもできます。

PBIは、実際のプロジェクト関連の価値を利害関係者にもたらす必要があります。コーディングや設計が本当に楽しいが、利害関係者に価値をもたらさない技術的なアイテムは、価値のあるソフトウェアを継続的に提供するというアジャイル原則の1つに違反します^[2]。

ユーザーストーリーの場合、ストーリー単体で顧客価値を持たなければならない^[3]。特定技術のみを扱い顧客が価値を想像しづらいストーリーは避けなければならない（失敗例: UIに特化したストーリー）^[4]。これはユーザーストーリーが技術に習熟していない顧客との会話のために存在するからである^[5]。

もしPBIサイズを見積もることができない場合は、計画もタスク化も行われません。したがって、スプリントの一部になることはありません。この種のPBIをプロダクトバックログに保持することににはまったく意味がありません。ほとんどの場合、ストーリーの説明自体に、またはプロダクトオーナーから情報が不足しているため、見積もりを実行できません。

プロダクトバックログのアイテムサイズは、最大でもスプリント内で完了できるサイズに保つようにしてください。

経験則として、単一の製品バックログアイテムはスプリントの50％を超えないようにします。その範囲を超えるものは、大きすぎて適切なレベルの確実性で推定できないと見なせます。これらの大きなPBIは「エピック」と呼ばれることがあります。最初から小さくする必要はなく、リーンのジャストインタイムの概念を踏襲し、２～３スプリント先までに実装するであろうアイテムについては小さい状態を維持したほうがよいでしょう。

プロダクトバックログのアイテムは、テストに通過していないと完了とは見なされません。テストできない場合はスプリントバックログの候補と見なされるべきではありません。これは、 TDD（テスト駆動開発）を採用しているチームには特に当てはまります。