「買い物客として、次回より早く決済できるように支払い方法を保存したい。」これはユーザーストーリーです。仕様書ではなく、文章で表現されます。アジャイルソフトウェア開発チームは、インデックスカードや付箋にこれを書き留めます。この形式によって、作成者は役割、目標、そして理由を明確に記述せざるを得なくなります。データベースのスキーマではなく、実際にその機能を使用するユーザーに焦点を当て続けることができるのです。

ユーザーストーリーは、1990年代後半にケント・ベックとロン・ジェフリーズによって普及しました。意図的に不完全な形で記述されています。カードは対話の約束であり、開発者、デザイナー、プロダクトマネージャーが詳細について話し合います。受け入れ基準は後から追加されます。ストーリーが大きすぎると「エピック」と呼ばれ、曖昧すぎるとバグが発生する可能性が高くなります。

3つのC

• Card: 紙に収まるくらい短い文章。
• Conversation: ギャップを埋める議論。
• Confirmation: それが機能することを証明するテスト。

良いストーリーは、独立性、交渉可能性、価値、評価可能性、簡潔性、そして検証可能性を備えている。頭文字をとってINVESTと略される。これは宗教ではない。チームによっては、ストーリーを仕事のストーリーとして記述することもある。「遅刻しそうな時は、ワンタップで支払いを済ませて電車に乗り遅れないようにしたい」。同じアイデアだが、表現方法が違うだけだ。