第6章 プロダクトバックログ

• プロダクトバックログ
  • プロダクトに求められる機能を、優先順位をつけてリスト化したもの
  • 優先順位されたPBIリスト
• プロダクトバックログアイテム
  • フィーチャーや機能項目を表したもの
  • ユーザーストーリーで書かれることが多い
  • 見積もりにはストーリーポイントが理想日をつかううことが多い
    • エピックは見積もりをしないかTシャツのサイズ程度の見積もりにする
    • 細かく分割したあとで、個々について数値で見積もることがある

グルーミング

グルーミングは以下の3つのアクティビティの総称

• PBIの作成と改良
• PBIの見積もり
• PBIの優先順位付け

参加するのは、POが主体となって、内外のステークホルダー、スクラムマスター、開発チームが参加する
最終判断はPOの役割
開発チームは各スプリントの作業量の最大一割程度までをグルーミングように確保すべき

プロダクトバックログ

原則一つのプロダクトごとにプロダクトバックログを一つ用意する
各プロダクトにはそれぞれ専用のプロダクトバックログがある
MS Officeを例にすると、 work excelなどでそれぞれプロダクトバックログがある

階層化バックログ

複数のプロダクトをまとめたプロダクトバックを用意して、フィーチャーエリアごとに専用のバックログを持つ構造もありえる
一番大きなプロダクトバックログにはチーフプロダクトオーナーを置く
詳細は12章の、リリーストレインを参照

複数チーム−単一プロダクトバックログ

チームのよって、スキルセットが違うので、チームごとにプロダクトバックログのビューを用意する
そのようにして、各チームはそれぞれのスキルセットに対応するフォーチャーだけを表示できる仕組みを用意する

単一チーム-複数プロダクト

できるだけ避けたい状態
できれば、このような状態をなくすのが良い

ここまでの感想や実際の現場との差異

• グルーミングでやっているPBIの見積もりをスプリントプランニングでやっている
  • PBIの見積もりはスプリントプランニング出するものではないのかもしれない
    • とはいえ、特に場所は決まっていないので、ウチのスクラムではそういうものとするのもありかも
• もしかして一つのプロダクトバックログには一つのサービスが紐付けられる？
  • ユーザー側ではユーザー側の、管理画面では管理画面のみたいに
• 現在は、一つのプロダクトバックログに複数のプロダクトのPBIが全部入っている
  • そして、それぞれのプロダクトのオーナーがプランナーの人なのかもしれない
  • POだったのはチーフプロダクトオーナーの役割に該当する