ユーザーストーリーとINVEST
ユーザーストーリー
JSTQB FLのシラバスによると、ユーザーストーリーとは、システムやソフトウェアのユーザー（または購入者）にとって価値のある機能であることを表したものです。
最も一般的な記述形式は、 「[役割]として[達成するゴール]を達成したい、それは[役割のための結果としてのビジネス価値]を実現するためだ」 という文章であり、その後に受け入れ基準が続きます。
この形式に沿って、一般的なオンラインショッピングサイトを想定した具体例を挙げてみます。
【ユーザーストーリーの具体例】
- [役割] として： オンラインショップの顧客として
- [達成するゴール] を達成したい： カートに入れた商品をクレジットカードで決済したい
- [ビジネス価値] を実現するためだ： 自宅にいながらスムーズに買い物を完了させるためだ
3つのC
このストーリーを正しく実装・テストするためには、 「3つのC」 と呼ばれる以下の側面を満たしながらチームで進めていく必要があります。
-
カード（Card）: 上記の「顧客として、クレジットカードで決済したい…」という文章をインデックスカードや電子的なボードに記録します。これが開発チーム全体の出発点になります。
-
会話（Conversation）: カードに書かれた内容をもとに、ソフトウェアがどのように使用されるかについて話し合います。ビジネス側、開発側、テスト側の3つの視点からコラボレーションし、共通のビジョンを得ます。「対応しているクレジットカードのブランドは？」「決済エラーが起きたときの挙動はどうする？」といった具体的な仕様をこの会話を通して詰めていきます。
-
確認（Confirmation）: 話し合いの結果として、実装されたストーリーをステークホルダーが受け入れるために満たすべき条件である 「受け入れ基準」 を定めます。
具体例における「受け入れ基準」は、例えば以下のようになります（受け入れ基準はテスト条件とみなすことができます）。
- 有効なクレジットカード情報が入力された場合、決済が完了し、注文完了画面が表示されること。
- 無効なカード番号が入力された場合、決済が拒否され、エラーメッセージが表示されること。
INVEST
また、優れたユーザーストーリーを作成するための条件として、頭文字をとった 「INVEST」 という原則があります。
- Independent（独立性がある）
- Negotiable（交渉可能である）
- Valuable（価値がある）
- Estimable（見積り可能である）
- Small（小さくて扱いやすい）
- Testable（テスト可能である）
もしチームの誰かが「このユーザーストーリーをどうテストすればいいかわからない」と感じる場合、それはストーリーの記述が不明確であったり、ユーザーにとっての価値が正しく反映されていないサインとなります。
そのため、ユーザーストーリーの作成（共同執筆）は、ブレーンストーミングなどを通じて、ビジネス側、開発側、テスト側の3つの視点からコラボレーションして行うことで、チーム全体で共通のビジョンを持つことができるとされています。