出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/08/05 01:45 UTC 版)
アジャイルソフトウェア開発プロジェクトのINVESTは、Bill Wake [1]によって作成され、良質の製品バックログアイテム（通常はユーザーストーリー形式で記述されていますが、必須ではありません）または略してPBIの特性を思い出させます。このようなPBIは、スクラムまたはかんばんのバックログまたはXPプロジェクトで使用できます。
| 文字 | 単語 | 意味 | 説明 |
|---|---|---|---|
| I | Independent | 独立している | PBIは、他のPBIに固有の依存関係がないように、自己完結型である必要があります。 |
| N | Negotiable | 交渉可能である | PBIは明示的な契約ではなく、議論の余地を残す必要があります。 |
| V | Valuable | 価値がある | PBIは、利害関係者に価値を提供する必要があります。 |
| E | Estimable | 見積もり可能である | PBIのサイズは常に見積もることができなければなりません。 |
| S | Small | 小さい | PBIは、正確さのレベル内で計画/タスク/優先順位付けを行うことが不可能になるほど大きくすべきではありません。 |
| T | Testable | テスト可能である | PBIまたはその関連する説明は、テスト開発を可能にするために必要な情報を提供する必要があります。 |
スクラム、かんばん、 XPなどのアジャイル手法の特徴の1つは、PBIを、労力をかけずに相対的な優先順位を考慮して移動できることです。強く依存しているPBIを見つけた場合は、それらを1つのPBIに結合し、大きなPBIを見つけた場合は、より小さく分割することをお勧めします。
PBIは、チームメンバーによって、ビジネス、市場、技術、その他の種類の要件に応じて、書き換えたり破棄したりすることもできます。
PBIは、実際のプロジェクト関連の価値を利害関係者にもたらす必要があります。コーディングや設計が本当に楽しいが、利害関係者に価値をもたらさない技術的なアイテムは、価値のあるソフトウェアを継続的に提供するというアジャイル原則の1つに違反します[2]。
ユーザーストーリーの場合、ストーリー単体で顧客価値を持たなければならない[3]。特定技術のみを扱い顧客が価値を想像しづらいストーリーは避けなければならない（失敗例: UIに特化したストーリー）[4]。これはユーザーストーリーが技術に習熟していない顧客との会話のために存在するからである[5]。
もしPBIサイズを見積もることができない場合は、計画もタスク化も行われません。したがって、スプリントの一部になることはありません。この種のPBIをプロダクトバックログに保持することににはまったく意味がありません。ほとんどの場合、ストーリーの説明自体に、またはプロダクトオーナーから情報が不足しているため、見積もりを実行できません。
プロダクトバックログのアイテムサイズは、最大でもスプリント内で完了できるサイズに保つようにしてください。
経験則として、単一の製品バックログアイテムはスプリントの50％を超えないようにします。その範囲を超えるものは、大きすぎて適切なレベルの確実性で推定できないと見なせます。これらの大きなPBIは「エピック」と呼ばれることがあります。最初から小さくする必要はなく、リーンのジャストインタイムの概念を踏襲し、２～３スプリント先までに実装するであろうアイテムについては小さい状態を維持したほうがよいでしょう。
プロダクトバックログのアイテムは、テストに通過していないと完了とは見なされません。テストできない場合はスプリントバックログの候補と見なされるべきではありません。これは、 TDD（テスト駆動開発）を採用しているチームには特に当てはまります。
