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

プラクティス名（別名）

プロダクトバックログ　（フィーチャーリスト、マスターストーリーリスト）

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

• プロダクトに対する要求事項（改善要望）を一覧化する（＝透明性を保つ）
• 最もユーザ価値が高いものから先にリリースする

どんな時に使うか

• 様々なステークホルダーから挙がった要求事項を整理し、共有したい時
• コストとメリットに基づき、関係者間で優先順位を決めたい時

実施手順（取り扱いルール）

略語	意味
PBL	プロダクトバックログ、要求事項のリスト全体
PBI	プロダクトバックログアイテム、記載された要求事項の１つ１つ
PBR	プロダクトバックログリファインメント、PBLのメンテナンス作業（追加/変更/分割/統合/削除/並び替え）

1. プロダクトに対する要求事項やアイデアを集め、ユーザ視点でリスト化する（PBL作成）
2. 各要求事項（PBI）はプロダクトゴールの達成に寄与するものであることが望ましい
3. DEVが各PBIを実現するためのコスト（作業量）を見積もり、追記する
4. コストを踏まえ、POの判断でユーザ価値が高い順にPBIを並び替える
5. PBLは定常的に見直し、優先度の高いPBIから段階的に詳細化する（PBR）
6. スクラムチームはPBLを唯一の情報源として行う作業を決定する

アレンジ例

• 要求内容をユーザーストーリー形式で記述する
• PBIごとに受け入れ条件（AC）を追記する
• コストを工数ではなく、タスクサイズの比較で相対的に見積もる（ストーリーポイント）
• 詳細化されていない粗い要求事項（エピック）も記載しておく
• 初回リリースに必要な最低限の機能（MVP）を絞り込む（ユーザーストーリーマッピング）
• ユーザ要望では無いが、間接的に必要となる作業もPBI化しておく（品質バックログ）

アンチパターン

• 優先順位が一意につけられていない（最優先のPBIが複数ある等）
• PO以外の人が了承を得ずに優先順位を変える
• ステークホルダーがPOの了承なく、直接PBLに要求事項を記載する
• PBLは全てPOが作成するもの、という思い込みでDEVがPBL管理を手伝わない
• 記述がシステム観点（機能一覧）になっていて、「なぜ」が書かれていない
• 全てのPBIを最初から詳細化しようとする（→優先度の低いPBIは後で詳細化すればよい）
• PBL（またはそれに類するリスト）が複数存在している
• 詳細仕様がびっしりと書き込まれていてPBLの見通しが悪い（→設計書や別欄に書く）
• 会話が無く、PBLの記述だけでやりとりしている

参考情報

公式スクラムガイド(2020年日本語版)

ryuzeeさんがPBLに関する知見を網羅的にまとめてくれている資料（RSGT2022にて発表）

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

スクラムユーザなら誰もが知るPBLをどう紹介したものか、と改めて考えました。記述粒度や記載テクニックなどは色々ありますが、結局は書き方よりもBiz-PO-DEV間のコミュニケーションツールとして機能しているかどうかが大事なのかな、と思います。適切な粒度は現場によって異なりますし、PBLの他に要件定義書や設計書を作成するかどうかによっても変わってきます。

また僕の職場ではPOに時間がなくDEVが代筆するケースがあるのですが、そうすると大抵記述がシステム目線になってしまっています。その半ば機能一覧と化したPBIをPOに並び替えてもらうと、価値基準ではなく、単にオペレーション順で優先順位がついて返ってきたりもします。（汗）

まぁ、ユーザ価値に基づいて優先順位をつけるための方法ってスクラムガイドには載ってないですからね。。。CSPO研修とかに行くとROI（投資対効果）に基づく順位付けの考え方などを教えてもらえます。最後に研修で教えていただいたPBLの説明を引用しておきます。

「PBLはユーザ価値を生む仮説の集合であり、価値を生む確率が高い順に並んでいる」

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