はじめに
スクラム(Scrum)を採用しているチームでは、「PBI」「プロダクトバックログ」という言葉が日常的に飛び交います。本記事では、PBI(Product Backlog Item、プロダクトバックログアイテム)が何を指すのか、それを束ねる「プロダクトバックログ」とはどんな存在なのかを、公式のScrum Guideに沿って整理します。
プロダクトバックログとは
プロダクトバックログ(Product Backlog) は、プロダクトの改善に必要な作業を一覧化した、単一の情報源(信頼できる唯一のリスト)です。新機能の追加、既存機能の改善、不具合の修正、技術的な改善など、プロダクトに対して行うべきことがすべてここに集約されます。
プロダクトバックログは一度作って終わりのものではなく、創発的(emergent) な性質を持ちます。つまり、プロダクトやその利用環境について理解が深まるにつれて、内容は継続的に変化し続けます。市場の状況、顧客からのフィードバック、技術的な発見などに応じて、常に更新され続ける「生きたリスト」です。
PBI(Product Backlog Item)とは
プロダクトバックログを構成する1つ1つの項目が、PBI(Product Backlog Item) です。「何かをする必要がある」という作業単位を表します。
重要なのは、PBIの書き方や形式に決まったルールは存在しないという点です。公式のScrum Guide自体もPBIのフォーマットを規定していません。実務では、後述する「ユーザーストーリー」形式で書かれることが多いですが、それ以外にも次のような形を取ることがあります。
- 新機能の追加要求
- 既存機能の改善要求
- 修正すべき不具合(バグ)の報告
- 信頼性・パフォーマンスといった非機能要件
- 検証したいアイデアや仮説・実験
PBIは「育っていく」もの
PBIは、最初から詳細に書かれているとは限りません。むしろ多くの場合、最初は曖昧なアイデアとして登録され、チームやプロダクトオーナーとの対話を通じて徐々に情報が肉付けされ、実際にスプリントに取り込めるレベルまで具体化されていきます。この、PBIの内容を継続的に見直し・詳細化していく活動を プロダクトバックログリファインメント(Product Backlog Refinement) と呼びます。
PBIの望ましい属性：DEEP
プロダクトバックログ、ひいてはそれを構成するPBI群が備えるべき性質として、しばしばDEEPという頭字語で説明されます。
| 頭文字 | 内容 |
|---|---|
| Detailed appropriately(適切に詳細) | 優先度の高いPBIほど詳細に、低いものは粗いままでよい(すべてを均一に詳細化する必要はない) |
| Estimated(見積もられている) | 各PBIには、作業量の目安(見積もり)が付いている |
| Emergent(創発的) | プロダクトバックログは固定的でなく、状況に応じて変化し続ける |
| Prioritized(優先順位付けされている) | 価値の高いものから順に並べられており、上位から着手される |
上位(直近着手予定)のPBIほど詳細に分割・見積もりされ、下位(まだ先の話)のPBIは大まかな粒度のままにしておく、というのが実務上の基本的な考え方です。
誰が管理するのか
プロダクトバックログの内容・並び順(優先順位)に対して最終的な説明責任を持つのは プロダクトオーナー(Product Owner) です。ただし、これは「プロダクトオーナーが1人で全部書く」という意味ではなく、開発チームや関係者からの意見を踏まえながら、最終的な優先順位の判断・責任を負う役割、という位置づけです。
まとめ
| 項目 | 内容 |
|---|---|
| プロダクトバックログ | プロダクトに必要な作業を一覧化した、唯一の情報源。継続的に変化し続ける |
| PBI(Product Backlog Item) | プロダクトバックログを構成する1つの作業項目。形式に決まったルールはない |
| リファインメント | PBIの内容を継続的に詳細化・見直しする活動 |
| DEEP | PBI群が備えるべき性質(詳細度・見積もり・創発性・優先順位付け)を表す頭字語 |
| 責任者 | プロダクトオーナーが、プロダクトバックログの内容と優先順位に説明責任を持つ |
なお、スクラム全体の役割・イベント・作成物については別記事「スクラムの基本を理解する」、PBIをユーザーストーリー形式で書く際の基準については別記事「ユーザーストーリーとストーリーポイントの基礎」で詳しく解説しています。