【プラクティス紹介】1分でさらっと分かる「プロダクトバックログアイテム分割」

プラクティス名（別名）

プロダクトバックログアイテム分割（ユーザーストーリー分割、縦切り、Vertical Slice）

プラクティスの目的・狙い

• 大きすぎるPBIをスプリント投入できるサイズに切り分ける
• １つのユーザストーリーに含まれる優先度の高い機能と低い機能を切り分ける

どんな時に使うか

• PBIがボリューム的に1スプリントの中でつくり切れない時
• スプリントの工数にまだ少し余裕があるが、次のPBIを拾うと溢れてしまう時
• MVPのサイズをできるだけ小さくしたい時

実施手順

1. 分割対象のPBIについて、より詳細なフィーチャー単位で切り分ける（＝縦切り）
   ※切り分けに困る場合は、ストーリーを具体化すると切れ目を見つけやすくなる
2. 切り分けた結果、PBIに依存関係が生じてしまうこともあるが、分割を優先する
3. ストーリーポイントを再度見積もる（その合計は元の値と一致するとは限らない）
4. 優先順位を見直す（分割前と同じ位置に並ぶとは限らない）

分割観点	具体例
ユースケースで分ける	問合せ業務で使う機能/分析業務で使う機能
業務ステップで分ける	検索/確認/修正/通知など、ビジネスフローに沿って
重要度で分ける	絶対に必要な機能/あれば嬉しい機能
使用頻度で分ける	よく使う機能/たまに使う機能
ユーザで分ける	一般ユーザ用/ゲストユーザ用/管理ユーザ用
受け入れ条件で分ける(AC)	受け入れ条件1を満たす/受け入れ条件2を満たす
操作で分ける(CRUD)	登録機能/参照機能/更新機能/削除機能
UI品質で分ける	見た目は粗いが一通り使える/使いやすく洗練されたUI
正常系と異常系で分ける	正常ケースのみ処理できる/異常ケースも処理できる
プラットフォームで分ける	iOS/Andoroid、Chrome/Edge/Firefox、各バージョン
規模・件数で分ける	1件ずつの処理/同時に10件処理できる
データ境界で分ける	特定データのみ対象/全データを対象とする
パフォーマンスで分ける	レスポンスが10秒以内/5秒以内/1秒以内
セキュリティ要件で分ける	参照権限/チェック/ロギング/脆弱性対応
実装難易度で分ける	実装が容易/難しい
調整難易度で分ける	他システムとのI/F連携が不要/必要

アレンジ例

• スプリントバックログアイテム（SBI）が1日で終わらないサイズになってしまう場合も同様の考え方で分割する

アンチパターン

• ストーリーポイント5のPBIを2つに分割し、それぞれのspを2.5とする
• 設計/実装/テストといった作業工程で分割する
  （設計だけ完了していてもスプリントレビューには出せない）
• 画面/サーバ処理/DBといったコンポーネント単位で分割する（＝水平スライス）
  （画面だけ完成していてもスプリントレビューには出せない）

垂直スライス	水平スライス
アジャイル的思考	ウォーターフォール的思考
価値提供のスピードを重視	開発者の作業効率を重視
１つのフィーチャーを実現するために必要な部分だけに絞って各層一気通貫で実装する方式	１つの部品を完成させるために将来的に必要なものの含め全ての要素を実装する方式
例：画面にはまだいくつかの項目しかないが、その部分についてはユーザが実際に操作し、使うことができる	例：画面には全ての項目が揃っているがバックエンドの処理がまだ実装されていないため実際にユーザが操作することはできない

参考情報

ryuzeeさんが分割観点についてまとめてくれています。より詳細に知りたい方にオススメです。

こぼれ話（私的コメント）

何かの記事で読んだ話です。あるコンサルさんがカンファレンスでワークショップを開催し、参加者から分割に困りそうなPBIを50個ほど挙げてもらい、皆で切り分けられるかどうかを話し合ったところ、分割できなかったものは1つも無かったそうです。つまり切れ目自体は無数にあるということでしょう。
おそらく「分割できない」と思ってしまう背景には、「これ以上、分割するとユーザにとっての価値が無くなってしまう」という思い込みがあるからではないかと推測します。確かに分割によってユーザが想定する一連のオペレーションが最後まで果たせなくなってしまうケースはあるでしょう。ただ途中まででも実物に触れ、操作を試すことで気づけることもあるハズです。そういった意味では分割後も何かしらの価値が残るのではないかと思います。
小分けにしてまず使ってみる、というのはアジャイルの戦術そのものなので、積極的に使っていきたいプラクティスです。

　アジャイルプラクティス一覧へ戻る