概要
機能開発で実現したい顧客の要望を指す。
例:「ユーザーは◯◯したい。それは▲▲だからだ」 意図の部分が大事。 なおかつ簡潔に書くことによってスクラムチームが着手前に話さざるを得ない状況をあえて作ることができる
もし物理的な制約などで頻繁に話すことができない場合は画面イメージ、受け入れ基準などでストーリーの詳細を補足する必要がある(とはいえドキュメントより対話を重視すべき)
開発要件の 「文書化」は難しい。小さいインデックスカードに顧客の要望を書くのが丁度いい。
- フィーチャの本質を捉えるキーワードを書き留める程度
- 細かい要求はあとで取り組む直前で分析する
- ユーザーストーリーは E2E になっていると良い
- UI→ ロジック →DB までが一貫されている
- 例:
- ユーザーアカウントを作成する
- 新規物件が投稿されたらメーリングリストに通知される
- メーリングリストの購読を停止できる
「よく書けた」ユーザーストーリー
-
他のストーリーに依存しておらず、独立している
-
「松案・竹案・梅案」のように交渉の余地がある
-
テストできる
- 例:期限切れアカウントでのログイン
- 通常のログインができる
- 期限切れログインはリダイレクトされる
- 適切なエラーメッセージを表示する
- 例:期限切れアカウントでのログイン
-
見積もれる程度の大きさである