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

本章では、スクラム開発プロジェクトにおいて最も重要な情報源である「プロダクトバックログ」の役割と、それを健全な状態に保つためのプラクティスについて解説します。

6.1 概要 と 6.2 プロダクトバックログアイテム

プロダクトバックログとは、プロダクトに求められる機能を優先順位付けしたリストです。 バックログの中身は「プロダクトバックログアイテム（PBI）」と呼ばれ、以下のようなさまざまな形式のものが含まれます。

• フィーチャー: 顧客に直接価値を提供する新機能（例：ユーザーストーリー）。
• 変更: 既存のフィーチャーの変更や改善。
• 不具合対応: バグの修正作業。
• 技術的な改善: データベースの移行などのリファクタリングや技術的負債の返済。
• 知識の獲得: プロトタイプの作成や概念実証（POC）などの調査タスク。

6.3 よいプロダクトバックログの特徴（DEEP）

よくできたプロダクトバックログは「DEEP」と呼ばれる4つの特徴を備えています。

• D（Detailed appropriately：適切な詳細度）: バックログの上部（優先順位が高い）にあるアイテムほど詳細に記述されサイズが小さく、下部にあるアイテムほど詳細度が低くサイズが大きくなります。
• E（Emergent：創発的）: プロダクトバックログは静的なものではなく、顧客のフィードバックや市場の変化に合わせて、絶え間なく更新（追加、削除、修正）され続けます。
• E（Estimated：見積り）: 個々のPBIには、そのアイテムの開発に要する作業量の見積り（ストーリーポイントなど）が割り当てられます。
• P（Prioritized：優先順位付け）: すべてのアイテムは、価値やコスト、リスクなどの要素に基づいて優先順位付けされ、最も価値の高いものがリストの上部に配置されます。

6.4 グルーミング

「グルーミング（リファインメントとも呼ばれる）」とは、プロダクトバックログを継続的に整備する活動です。

• 活動内容: PBIの作成と改良、見積り、優先順位付けの3つを含みます。
• 誰が行うか: プロダクトオーナーが主導しますが、スクラムマスターや開発チーム全員、さらに必要に応じてステークホルダーも参加する共同作業です。
• いつ行うか: リリースプランニングの際だけでなく、スプリント中も定期的に行われます。目安として、開発チームはスプリントのキャパシティの最大10%をこのグルーミングに割り当てることが推奨されます。

6.5 準備完了の定義（Definition of Ready: DoR）

スプリントにアイテムを投入する前に、そのPBIが「準備完了」状態になっているかを判定するチェックリストです。

• 目的: 曖昧な要件のままスプリントを開始し、開発チームが作業を進められなくなる（ブロックされる）事態を防ぎます。
• チェックリストの例:
  • ビジネス上の価値が明確になっている。
  • 依存関係が特定されており、ブロックされない。
  • スプリントに収まるサイズに見積り済みである。
  • 受け入れ条件が明確になっている。
  • パフォーマンス要件などが定義され、テスト可能である。

6.6 フローの管理 と 6.7 バックログの数

バックログは、要件が流れ込む「パイプライン」として機能します。

• フローの不一致: グルーミングによってアイテムを準備する速度と、開発チームがスプリントで消化する速度にミスマッチがあると、無駄が生じたり、開発が停滞したりします。
• バックログの数: 原則として「1つのプロダクトにつき1つのプロダクトバックログ」を用意します。
  • 複数チームで1つのプロダクトを開発する場合も、バックログは1つに統合して優先順位を一元管理します。
  • 1つのチームが複数プロダクトを担当する場合、コンテキストスイッチの無駄が生じやすいため、できる限り1つのバックログにまとめるか、スプリントごとに焦点を絞る工夫が必要です。

6.8 終わりに

本章では、価値の提供を確実にするためのプロダクトバックログの役割、DEEPな特性、グルーミング、そして「準備完了の定義」について解説しました。次章では、このバックログアイテムの見積り方法やベロシティについて深く掘り下げます。