ユーザストーリーは手間をかけない要求の表し方である。アジャイルなプロジェクトでは、時間のかかる形式張ったユースケースではなく、ユーザストーリーを用いている。ユースケースのようにすべての詳細を記述してしまうと、顧客が要求を変えたとき、対応しにくくなる。一方ユーザストーリがもたらすのは、開発者とプロダクト・オーナーの話し合いをスタートするのに必要最小限の情報だ。ユーザストーリーはエンドユーザに価値を提供する、機能の最小単位でもある。例えば次のような感じだ (Mike Cohn氏の(source)『Advantages of User Stories for requirements』(source)より)。
- ユーザはウェブサイトに業務経歴書を掲載することができる。
- ユーザは求人を検索することができる。
- 企業は新規の求人を掲載することができる。
- ユーザは自分の業務経歴書を誰に見せるか、制限できる。
Bill Wake氏はよいストーリーの条件を表す単語の頭文字をとって「INVEST」(source)という略語を考案した。: ちなみに、よいストーリーとは次のような条件を満たすストーリーである。Independent(独立している)、Negotiable(対話を引き出す)、Valuable(ユーザ価値を提供する)、Estimable(見積り可能である)、Small(小さい)、Testable(テスト可能である)。
Patrick氏が言うように、よいストーリーを書くコツはどれくらい詳細に書くか、そしていつ書くかを知ることだ。早い段階で、ユースケースのようにあまりにも詳細まで詰めてしまうと、実装するまでにストーリーを何回も書き直す羽目になる。逆に、あまりにも大雑把すぎると、開発者は何を計画して何を実装すればよいのか分からなくなってしまう。Patrick氏は次のように書いている(source)。
いますぐ実装に取りかかるストーリーについては、開発者やテスターが何を達成しなければならないのか、はっきりと分かるくらい十分な細かさが求められます。ここで詳細まで詰め切れていないと、続く工程で手直しが頻発するというムダにつながります。
…一方、ずっと後で実装すればよいストーリーについては、同じレベルの詳細さは必要はありませんあまりにも早い時期に詳細を捉えようとすると、分析レベルでの手直しが発生するというムダにつながります。
したがって、最初の質問への答えは、「場合による」だ。なぜなら、ストーリーが先の話であればあるほど、詳細は必要ない。まさにいま取り組もうとしてるストーリーについてのみ、テストケースに落とし込めるくらいまで詳細にすればよいのだ。
全文はこちら。『How much detail should you put in your story?』(source)(Pat Kua氏の(source)サイト)
原文はこちらです：http://www.infoq.com/news/2008/02/size-user-stories