INVEST

アジャイルソフトウェア開発プロジェクトのINVESTは、Bill Wake Bill Wake's original article: INVEST in Good Stories, and SMART Tasksによって作成され、良質の製品バックログアイテム（通常はユーザーストーリー形式で記述されていますが、必須ではありません）または略してPBIの特性を思い出させます。このようなPBIは、スクラムまたはかんばんのバックログまたはXPプロジェクトで使用できます。
文字単語意味説明IIndependent独立しているPBIは、他のPBIに固有の依存関係がないように、自己完結型である必要があります。 NNegotiable交渉可能であるPBIは明示的な契約ではなく、議論の余地を残す必要があります。 VValuable価値があるPBIは、利害関係者に価値を提供する必要があります。 EEstimable見積もり可能であるPBIのサイズは常に見積もることができなければなりません。 SSmall小さいPBIは、正確さのレベル内で計画/タスク/優先順位付けを行うことが不可能になるほど大きくすべきではありません。 TTestableテスト可能であるPBIまたはその関連する説明は、テスト開発を可能にするために必要な情報を提供する必要があります。

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

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

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

ユーザーストーリーの場合、ストーリー単体で顧客価値を持たなければならない"A story needs to be valuable. ... it needs to be valuable to the customer. ... concerns ... in a way that makes the customer perceive them as important." Bill Wake. (2003). INVEST in Good Stories, and SMART Tasks. XP123.。特定技術のみを扱い顧客が価値を想像しづらいストーリーは避けなければならない（失敗例: UIに特化したストーリー）"when splitting stories. ... We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers." Bill Wake. (2003). INVEST in Good Stories, and SMART Tasks. XP123.。これはユーザーストーリーが技術に習熟していない顧客との会話のために存在するからである"A pidgin language ... stories act as a pidgin language where both sides can agree enough to work together effectively."。

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

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

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

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

 関連項目 

 要求工学
 アジャイルソフトウェア開発
 範囲 (プロジェクト管理)
 品質管理

 外部リンク 

 ジェフサザーランドのブログ
 https://agileforall.com/new-to-agile-invest-in-good-user-stories/
 https://www.agilealliance.org/glossary/invest

 参考文献 

Category:記憶術
Category:頭字語
Category:ソフトウェア開発工程
Category:アジャイルソフトウェア開発
Category:スクラム