プロダクトバックログ
- スクラムの成果物（アーティファクト）の一つ
- プロダクトに必要なものを順番に並べた一覧
- POが内容、可用性、並び順に責任
- PBI（プロダクトバックログアイテム）
プロダクトバックログの内容
- 詳細・並び順・見積り・価値の属性
- テストも含まれる
- プロダクトが存在する限り、プロダクトバックログも存在し続ける（プロダクトが改善しつづける）
並び順
- 上部にあるものが優先
- not 優先度, 優先順
- 優先順位が高いものほど明確で詳細
- 高いものほど見積もりされやすい
デイリー
- 昨日行ったこと
- 今日行うこと
- 困っていること
参考
Scrum Guide 2017
プロダクトバックログ
プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。
プロダクトに対する変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログ
の内容・可用性・並び順に責任を持つ。
プロダクトバックログは決して完成しない。構築の初期段階には、明確でよく理解できている要求
が並べられている。その後、プロダクトや使用環境に合わせて進化する。プロダクトバックログは動
的であり、適切で競争力のある有用なプロダクトに必要なものを求めて絶えず変化する。プロダク
トが存在する限り、プロダクトバックログも存在し続けるのである。
プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正
をすべて一覧にしている。プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性が
ある。プロダクトバックログアイテムには、「完成」時にそれを確認するためのテスト記述も含まれて
いることが多い。
プロダクトが使用されて価値が増加し、市場からフィードバックを得られると、プロダクトバックログ
は巨大で包括的な一覧になる。要求の変更は止まらない。プロダクトバックログは生きた作成物で
ある。ビジネス要求、市場の状態、技術の変化などが、プロダクトバックログの変化につながる。
複数のスクラムチームが同じプロダクトの作業をすることがよくある。そうした場合、プロダクトの作
業は 1 つのプロダクトバックログに記述する。また、アイテムを分類するための属性をプロダクトバ
ックログに追加することもある。
プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プ
ロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う
継続的なプロセスである。プロダクトバックログのリファインメントによって、アイテムのレビューと改
訂が行われる。いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメ
ントは、開発チームの作業の 10%以下にすることが多い。ただし、プロダクトバックログアイテムは
プロダクトオーナーの判断によって、いつでも更新できる。
並び順が上のプロダクトバックログアイテムほど明確で詳細である。明確で詳細であれば、見積り
も正確になる。並び順が下のアイテムほど不正確で詳細ではない。今後のスプリントで開発チーム
が従事するプロダクトバックログアイテムは、スプリントのタイムボックスで「完成」できるようにうまく
細分化する。開発チームが 1 つのスプリントで「完成」できそうなプロダクトバックログアイテムは、ス
プリントプランニングで選択できる「準備完了（Ready）」の状態になったと見なすことができる。プロ
ダクトバックログアイテムは、上記のリファインメントによって透明性を獲得することが多い。
開発チームは見積りに対して責任を持つ。プロダクトオーナーがトレードオフの理解や選択などに
ついて開発チームに影響を及ぼすこともあるが、最終的な見積りは実際に作業をする人が行う。