🚀

スクラムにおけるプロダクトバックログとは何だろうか

に公開

スクラムにおけるプロダクトバックログとは

はじめに

スクラムを取り入れてアジャイル開発を実践しているチームの中で、よく使われる言葉の1つが「プロダクトバックログ」です。けれど、「プロダクトバックログって具体的には何?」「どう書けばいいの?」「リファインメントって何のためにやるの?」といった疑問を持つ方も少なくありません。

この記事では、スクラムにおけるプロダクトバックログの役割や構成要素、実践的な書き方やリファインメントの方法について、サンプルを交えてわかりやすく解説します。

プロダクトバックログとは?

プロダクトバックログは、創発的かつ優先順位順に並べられた、プロダクトの改善に必要な項目の一覧です。これはスクラムチームが行う作業の唯一の情報源です。スクラムチームがスプリントで行う内容は基本的にここに入ります。

以下の2つの要素で構成されています。

  • プロダクトゴール
  • プロダクトバックログアイテム(PBI)

プロダクトゴールとは?

プロダクトゴールは、プロダクトの将来の状態を示す目標です。

  • スクラムチームが向かう「北極星」のような存在
  • スプリントごとに、そのゴールに近づくための価値を積み上げていく
  • スクラムガイドにおける5つの価値の1つ、「確約(Commitment)」に相当

例:プロダクトゴールのサンプル

ゴール例:「ユーザーが毎日の食事を簡単に記録でき、健康管理に役立つダッシュボードを持つこと」

このゴールに向かって、PBIが並んでいくことになります。

プロダクトバックログアイテム(PBI)とは?

PBIは、プロダクトゴールを実現するための「何をするか(What)」を表します。プロダクトの要求事項であり、スクラムチームがスプリントで扱う単位でもあります。

PBIの特徴

  • 優先度の高いものから順番に並べられる
  • 書き方はスクラムガイドで明確には定められていない
  • 最低限、「やることの内容」と「見積もり」は必要

スプリントプランニングとの関係

プロダクトバックログアイテムは、スプリントプランニングの場でスクラムチームによって選択され、そのスプリントの中で価値ある成果(=インクリメント)に変換されます

このとき重要なのは、

  • チームがどのPBIに取り組むかを自ら選ぶこと
  • 選ばれたPBIはスプリントゴールの達成に貢献するものであること
  • PBIが明確でないと、スプリント内で価値に変えることが難しくなる

つまり、プロダクトバックログが整備されていることは、スプリントの成功に直結するのです。

リファインメントとは?

PBIは、そのままではスプリント内で実行できる粒度ではないことも多く、詳細化する必要があります。
これを「リファインメント」と呼びます。リファインメントとは精緻化とか洗練化とかいう意味ですね。

リファインメントで行うこと

  • PBIの内容を詳細化して理解をそろえる
  • 見積もりをし、サイズが大きい場合は分割
  • 誰が見ても「やること」がわかる状態にする

これはスクラムの3本柱の1つである透明性 の実践でもあります。
透明性とは、何が入っているかが透明なビンで外から見てわかるイメージです。ビンがラベルとかが貼ってあって透明じゃないと、そのビンを受け取った人は何が入っているかがわかりません。

プロダクトバックログはどう書くのか?

スクラムガイドではPBIの具体的な書き方までは定められていませんが、現場ではユーザーストーリー形式
を用いることがあります。

ユーザーストーリーの書き方

ユーザーストーリーは以下のように書くのが一般的です。

[誰]として [何]をしたい なぜならば[理由]だからだ

例:ユーザーストーリーのサンプル

ユーザーストーリーのサンプルをChatGPTに提案してもらいました。以下のような記述になります。

ストーリー
「ユーザーとして、日々の食事を記録できるようにしたい。なぜなら、摂取カロリーを可視化したいからだ。」

このストーリーを実現するために、必要な作業(タスク)や実装項目を洗い出し、見積もりとともにPBIとして管理します。

PBIの分割例

スプリントで完了できないような大きなPBIは、以下のように分割します。例は先ほどのユーザーストーリーで出したものです。

分割前のPBI(大きすぎる)

「食事記録機能を実装する」 =>
「ユーザーとして、日々の食事を記録できるようにしたい。なぜなら、摂取カロリーを可視化したいからだ。」

分割後のPBI例

  1. 朝食・昼食・夕食の入力フォームを作る(正常系) =>
    「ユーザーとして、朝食・昼食・夕食を入力したい。なぜならば、摂取カロリーを可視化するために記録したいからだ」
  2. 入力時のバリデーションを実装(異常系)=>
    「ユーザーとして、入力された値が正しいかわかるようにしたい。なぜならば、間違った入力だと正しい記録にならないからだ」
  3. 保存後の一覧画面を作成する =>
    「ユーザーとして、自分が入力した食事の情報を一覧で見たい。なぜならば、自分の食事の情報を振り返って改善点を見つけたいからだ」
  4. ユーザーごとにデータを保存する認証処理を追加する =>
    「ユーザーとして、に自分の食事データだけが保存されるようにしたい。なぜならば、自分の食事の内容だけ管理したいからだ」
  5. データベースへの永続化処理 =>
    「ユーザーとして、自分が入力した食事の情報を保存できるようにしたい。なぜなら、後から食事の履歴を見返して健康管理に活用したいからだ」

このように分割していくことで、スプリントで確実に完了できる粒度にまで落とし込みます。

まとめ

プロダクトバックログは、スクラムチームにとって唯一の作業の情報源です。
明確なプロダクトゴールと、それを達成するための具体的なPBIがしっかりと定義されていれば、チームは迷わず価値あるプロダクトを作っていくことができます。

  • プロダクトゴール:目指す未来の姿
  • PBI:ゴールに向かうためのやることリスト
  • リファインメント:PBIをスプリントで扱えるようにするための作業
  • ユーザーストーリー:PBIを書くうえで実践的なフォーマット
  • スプリントプランニング:PBIを選び、インクリメントに変える場

プロダクトバックログの健全な管理は、スクラムチームの成果を大きく左右します。透明性を保ち、価値あるインクリメントを継続的に生み出せる仕組みを育てていきましょう。

ドクターメイト

Discussion