はじめに
筆者は e-dash でエンジニアをしている yuki_nomura です。
こちらはe-dash advent calendar 2024の 10 日目の記事にあたります。
早速ですが、タイトルの「バックログを分けましょう」について補足させてください。
プロダクトバックログとスプリントバックログは分けましょう
これが、本記事でお伝えしたい趣旨です。
（「チームごとにバックログを分けるべき」という意味ではありません。なお、プロダクトバックログは基本的に 1 つに統一されていることが推奨とされています）
この記事では、2 つのバックログの違いを解説しながら、より良いバックログ活用を具体例を交えて紹介していきます。
参考：スクラムガイド：「スクラムの成果物」の章にもバックログについて掲載されています。
バックログとプロダクトの関係
まず、「バックログとは何のためにあるのか」という基本的な問いに立ち返ります。
「スクラムを回すため」でしょうか。それとも「プロジェクトを完結させるため」でしょうか？
ここでは、バックログの目的を 「プロダクトをより良くするため」 と定義します。
多くのサービスは、何らかのプロダクトを中心とした形で提供されています。プロダクトをサービスとバックログの文脈で見比べると、次のような整理ができます。
- 提供中のサービス： プロダクトの「現在の姿」
- バックログ： プロダクトの「未来の姿」
プロダクトの価値は、現在の価値と未来の期待値を足し合わされた合計値 で捉えることが一般的です。
バックログは、その「未来の期待値」を見える化したものであり、バックログの質を高めることは、プロダクトの価値向上に直結します。
スクラム開発において、バックログは 1 つの重要な成果物です。
プロダクトを見る景色は人によって異なる
スクラム開発においては、次の 3 つの役割が求められます。
- プロダクトオーナー（以下 PO）
- スクラムマスター
- 開発者
本記事では、プロダクトに直接関わる PO と開発者に焦点を当てます。スクラムマスターについては、プロダクトとの関わりが間接的なため、ここでは触れません。
開発者
開発者は主にソースコードを通じてプロダクトと対話します。
ソースコードの品質を高め、スプリント毎にインクリメントを作っていくことに責任を持ちます。
プロダクトの「現在の姿」を最もよく見ているのが開発者だと言えるかもしれません。
PO
一方で PO は、バックログを通じてプロダクトと対話します。
プロダクトの価値を最大化し、ROI （投資対効果）を最大にする責任を持っています。
そのため、プロダクトの先の「未来の姿」を見ていると言えます。
開発者と PO は共にプロダクトをよくすることを目指していますが、それぞれ異なる視点からプロダクトを見ています。
この違い自体は問題ではありませんが、お互いの視点の違いを認識しておくことが重要です。
プロダクトバックログとスプリントバックログの違い
まず、プロダクトバックログとスプリントバックログの役割の違いを明確にします。
プロダクトバックログ
- 顧客視点でアイテムを管理する
- PO の持ち物
スプリントバックログ
- スプリント中のタスクやチームの進捗を管理する
- 開発者 の持ち物
プロダクトバックログには「未来のイメージ」が優先順位に従って並んでいることが理想です。一方で、スプリントバックログは「現在の状態」がリアルタイムに反映されていることが望まれます。
バックログを区別をせず、「◯◯ の API を作成する」といった詳細なタスクがプロダクトバックログに混在してしまうケースをよく見かけます。
これは PO 管理すべき「未来の姿」とはかけ離れた内容です。
PO と開発者の役割の違いを意識しなければ、バックログが混沌としてしまうことは容易に想像できます。
運用変更の手順
実は e-dash も例に漏れずバックログを混沌とさせてしまっていました。
ここからは、実例を元にバックログの改善を試みた手順を見ていきます。
振り返りから始める
一度に全てを変えることは難しいため、まずは課題を明確にします。
振り返り（レトロスペクティブ）は、課題を見つけるための最適な場です。
e-dash では振り返りの結果、次の 2 点が課題として浮かび上がりました。
- バックログの粒度がバラバラでアイテム全てを把握できる人がいない
- 目的が不明瞭なアイテムが存在する
これらの課題に対する具体的な解決策を以下で説明します。
課題 1：バックログの粒度がバラバラ
バックログの粒度を揃えるために、以下のアプローチを取りました。
- アイテムを「ストーリー・バグ」と「タスク」に分ける
- 「ストーリー・バグ」は PO が管理し、優先順位をつける（プロダクトバックログ）
- 「タスク」は開発者がスプリントで取り組む対象として管理する（スプリントバックログ）
e-dash は Notion でバックログを管理しており、（関連付けを行った上で）データベースを分けることで明確に役割分担を行いました。
課題 2：目的が不明瞭なアイテム改善
目的が曖昧なアイテムを改善するため、 リファインメント を導入しました。
リファインメントでは次のようなポイントを意識しています。
- 関係者を全て集める: 「チーム全員」である必要はないことに注意
- 説明ができる人を事前に決める: セレモニーを円滑に進めるため
- チケットのポイント付けは大まかな認識合わせを重視する: フィボナッチ数の隣の数（2 と 3, 5 と 8 など）は誤差と捉え、数字にあまりこだわらない
イベントの流れは以下のとおりです。
まとめ
バックログはプロダクトの重要な一部です。その価値を高めることは、プロダクトの価値向上に直結します。バックログをメンバー全員でメンテナンスをし続けることがプロダクトの成長、ひいてはサービスの拡大に繋がると考えています。
本記事で紹介した内容が、皆さまのスクラム開発の一助となれば幸いです。
また、この記事の内容を社内に展開した際にスライドを作っていました。
それを少し一般化して公開したものがこちらです。もし興味を持って頂けた方はご参照ください。
Discussion