ビル・ウェイク の INVEST

ビジネス価値を生み出す作業や、チームの時間や労力を要する事柄はすべて、プロダクトバックログに載せてください。

バックログリファインメントには、プロダクトオーナーと職業横断的で自己組織化された開発チームが参加します。必要とされた時や求められた時のみスクラムマスターも参加します。ここでは、顧客やエンドユーザーも含めるべきです。 大規模スクラム（LeSS)ではさらに他のチーム、またはチームの代表者を含めることになります。

プロダクトバックログリファインメントの目的の一つは、洗練されたプロダクトバックログアイテムを作ることです。洗練されたプロダクトバックログアイテムは、独立し、交渉可能で、価値があり、見積もりが可能で、小さく、テスト可能です。

INVEST は次の略です。

• INDEPENDENT（独立した）: 伝統的な開発は、家を建てるようなものです。伝統的には、壁や屋根を作る前に床を作ります。 対照的に、最新のエンジニアリングプラクティスは依存関係を減らします。これにより、プロダクトオーナーは、ビジネス価値にもとづいて、プロダクトバックログアイテムの優先順位を常に変更することができます。プロダクトバックログアイテムを特定の順序で実現する必要がある場合、それらはまだ独立したものではありません。
• NEGOTIABLE（交渉可能）: プロダクトバックログアイテムは会話の一部です。ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。https://agilemanifesto.org/iso/ja/principles.html を参照。
• VALUABLE（価値のある）: 洗練されたプロダクトバックログアイテムは顧客中心で、エンドユーザから見ると、ビジネス上の価値は明らかです。
• ESTIMABLE（見積もり可能）: プロダクトバックログアイテムの大まかな見積もりに合意できないということは、まだそのプロダクトバックログアイテムを理解できていない証拠です。この場合、さらにリファインメントが必要です。
• SMALL（小さい）: ひとつのプロダクトバックログアイテムを完成させるためのチームの努力を考えてみましょう。これには、すべてのテスト、統合、コードのリファクタリング、その他「完成の定義」に到達するために必要なすべてが含まれます。もし総作業量がスプリントの4分の1より大きければ、プロダクトバックログアイテムは小さいとは言えません。この場合も、さらにリファインメントが必要です。
• TESTABLE（テスト可能）: 各プロダクトバックログアイテムは、明確なゴールを持つべきです。これが自動で実行可能なテストで書かれていれば、なお良いでしょう。

以下も参照してください。

• https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ by Bill Wake
• 実例による仕様 Cucumber/Java Specification By Example (SBE) 電子バーテンダー
• 近日公開、 スクラムトレーニングシリーズ ・ モジュール2

MJはこの記事を翻訳してくれた清水弘毅氏に感謝している。