プロダクトバックログ

要望がチケットに蓄積されても、どれから取り組むべきかがわからなければ、開発を始めるたびに交渉が必要になります。
プロダクトバックログ（Product Backlog）は、プロダクトの改善に必要な仕事を順序づけ、学んだことに応じて更新していく一覧です。
スクラムチームが取り組む仕事の唯一の情報源になります。

ゴールを仕事へ具体化する

プロダクトバックログには、チームが長期的に目指すプロダクトの状態であるプロダクトゴールを含めます。
それぞれの項目は、その状態へ近づくために何を変えるかを具体化します。
対象は新機能に限らず、不具合の修正、使い勝手の改善、調査、技術的な改善なども含みます。

たとえば「担当者が請求の誤りを送付前に発見できる状態」を目指すなら、候補は次のように並べられます。

  • 合計金額と内訳の不一致を表示する。
  • 誤りが起こる入力条件を調べる。
  • 過去の請求と比較できるようにする。
  • 金額計算の自動テストを追加する。

この時点で、すべての項目を作ると約束する必要はありません。
たとえば調査から誤りの原因がわかれば、比較画面を作るより、入力方法を直すほうがよいと判断することもあります。
バックログは、得られた情報から内容と順番を変えるために使います。

順番に判断の理由を表す

項目の順序と、バックログが理解できる状態にあることには、プロダクトオーナーが責任を持ちます。
価値の見込み、緊急性、依存関係、不確実さ、作業の大きさなどを判断材料にします。
全項目に「優先度：高」と付けても、次に取り組む仕事は決まりません。

先ほどの例では、計算の誤りが送付後の訂正を生んでいるなら、その原因の調査や修正を上へ置く判断が考えられます。
関係者には、誰が強く要望したかだけでなく、何を確かめ、どの問題を先に解くための順番なのかを伝えます。
使う予定の薄い項目は、状況が変わったときに削除することも検討します。

着手が近い項目から詳しくする

上位の項目は、スプリント内で完成できる大きさにし、目的と範囲を開発者が理解できるようにします。
「請求管理を改善する」では大きすぎるなら、「送付前に合計と内訳を比較できる」といった範囲へ分割します。
必要に応じて、結果を確認する条件や未解決の疑問も加えます。

こうした整理をバックログリファインメントと呼びます。
項目の大きさを見積もるのは、実際に仕事をする開発者です。
遠い将来の項目まで細かく決めると、状況が変わったときに書き直す量が増えるため、着手が近い仕事から理解を深めます。

スプリントバックログとの違い

プロダクトバックログは、今後プロダクトをどう改善するかという仕事の候補を扱います。
これに対してスプリントバックログは、今回のスプリントの目的、選んだ項目、実現するための計画をまとめた、開発者のための計画です。
全体の候補と、いま進めるための計画を分けることで、どの変更を誰と話し合うべきかを判断しやすくなります。

バックログの整備状況だけで、開発の成果は判断できません。
項目を消化した結果、プロダクトゴールへ近づいたかを、完成した成果や利用状況から確かめます。

参考資料