ユーザーストーリーについて、より正確な見積もりが必要な場合に分割する。
- あるフィーチャがリリースに含まれるかどうかギリギリの場合など
データ境界に沿って分割する
「ユーザーとして、バランスシートの情報を入力できる」をユーザーが入力するデータの種類に対応させて分割する。
- 「ユーザーとして、バランスシートのデータをサマリで入力できる」
- 資産と負債の2つだけを入力できるようにする
- 「ユーザーとして、バランスシートにカテゴリごとの入力ができる」
- 現金預金、投資有価証券、不動産など1レベル詳細化した項目を扱うようにする
- 「ユーザーとして、入力を間違えないような入力値のバリデーションがほしい」
- チームで話し合ってバリデーションの内容を決める。(負の値も入力できるなど）
- 「ユーザーとして、貸付金の詳細を入力できる」
- ユーザは100件まで貸付金を入力できるようにした
操作の境界で分割する
- CRUD操作を境界にする
- 「コーチとして、チームの選手を管理できる」
- コーチとして、新しい選手をチームに追加できる
- コーチとして、チームの選手の情報を編集できる
- コーチとして、チームから抜けた選手を削除できる
横断的な関心事を分離する
- セキュリティ、ロギング、エラーハンドリングなどを別ストーリーに分離する
- 横断的な機能を含まないストーリーと、含むストーリーの2つに分ける
優先度に沿ってストーリーを分割する
ログイン機能の場合、基本部分を優先し、ロギングや再試行回数制限といった補足的な要素は優先度を落とす。
⚠️ ストーリーをタスクに分解しない
- NG: 「UIを実装する」「中間層を実装する」
- OK: UI・中間層・DBの一部を部分的でもいいので実装する（曳光弾）。
⚠️ 関連する変更への誘惑を断つ
- 「ついでにこの変更もやれるじゃないか」をしない。
- 半日かけて1年前のバグを修正するか、他の作業をするかは状況によって異なるはず。
ストーリーをまとめる
イテレーションの長さによってストーリーの粒度を変える。
- ２週間のイテレーションなら、2~5日で完了できる大きさにストーリーを分割する。
- 1週間のイテレーションならもう少し小さくする。