製品バックログ - その概要と作成方法

A well-prioritized agile backlog not only makes release and iteration planning easier, it broadcasts all the things your team intends to spend time on—including internal work that the customer will never notice. This helps set expectations with stakeholders and other teams, especially when they bring additional work to you, and makes engineering time a fixed asset.

製品バックログとは、製品ロードマップと要件に基づいて開発チームが行う作業に優先順位を設定したリストです。製品バックログの一番上に最重要項目が表示されるので、チームは最初に取り掛かることがわかります。チームが製品所有者のぺースでバックログを処理することも、製品所有者が開発チームに作業を指示することもありません。開発チームは余裕があるときに製品バックログから継続的 (カンバン) または反復的 (スクラム) に作業を引き出します。

チームのロードマップと要件は、プロダクト バックログの基礎を成すものです。ロードマップのイニシアチブは複数のエピックに分割され、各エピックに複数の要件とユーザー ストーリーがあります。「Teams in Space」という架空の製品のロードマップを見てみましょう。

ロードマップの最初のイニシアチブは「Teams in Space」の Web サイトであるため、このイニシアチブをエピック (ここでは緑、青、ティールで表示) と各エピックのユーザー ストーリーに分割します。

次に、プロダクト所有者は各ユーザーストーリーを開発チーム用の単一リストに編成します。プロダクト所有者は最初に 1 つの完全なエピックを作るか (左)、複数のエピックでストーリーを構成します (右)。後者は割引フライトのテスト予約のように、プログラム上重要であることもあります。以下に、それぞれの例を示します。

プロダクトオーナーの優先順位設定に影響する要素は何ですか？

• 顧客の優先事項
• フィードバック取得の緊急度
• 実装の相対的な難易度
• 作業項目間の共生関係 (A を先に完了すると B が容易になるなど)

プロダクト所有者はバックログの優先順位を設定する必要がありますが、他と無関係に行うわけではありません。効果的に活動するプロダクト所有者は、顧客、デザイナー、開発チームから情報とフィードバックを受け、全員の作業負荷とプロダクト デリバリーを最適化します。

製品バックログを構築した後は、プログラムに応じて定期的にメンテナンスすることが重要です。製品所有者はイテレーション計画ミーティングの前にバックログをレビューし、優先順位が正しく、最終イテレーションからのフィードバックが反映されていることを確認する必要があります。バックログを定期的にレビューすることを、アジャイルの世界では「バックログ・グルーミング」と呼びます（バックログ・リファインメントという用語を使用することもあります）。

Once the backlog gets larger, product owners need to group the backlog into near-term and long-term items. Near-term items need to be fully fleshed out before they are labeled as such. This means complete user stories have been drawn up, collaboration with design and development has been sorted out, and estimates from development have been made. Longer term items can remain a bit vague, though it's a good idea to get a rough estimate from the development team to help prioritize them. The key word here is "rough": estimates will change once the team fully understands and begins work on those longer term items.

バックログは、プロダクト所有者と開発チームの間をつなぐ役割を果たします。プロダクト所有者は顧客からのフィードバック、見積もりの精緻化、新規要件をもとに、バックログでの作業の優先順位を自由に再設定できます。作業開始後は、開発チームの集中力、作業フロー、意欲の妨げとなることのないよう、変更は最小限に留めましょう。

注意すべきアンチパターン

• プロダクトオーナーはプロジェクト開始時にバックログの優先順位を設定するが、開発者や利害関係者からのフィードバックを受けても調整を行わない。
• バックログの項目が顧客向けのものに限られている。
• バックログはローカル文書として保存され、共有されることが少ないため、関係者が更新を受け取ることがない。

熟練したプロダクトオーナーはプログラムのプロダクトバックログを厳密にグルーミングし、プロジェクトの作業項目の信頼性を高めて共有できるようにします。

Stakeholders will challenge priorities, and that's good. Fostering discussion around what's important gets everyone's priorities in sync. These discussions foster a culture of group prioritization ensuring everyone shares the same mindset on the program.

製品バックログは、イテレーション計画の基礎にもなります。バックログにはすべての作業項目を盛り込みます（ユーザー・ストーリー、バグ、設計の変更、技術的負債、顧客からの依頼、過去に遡っての要処理事項など）。これにより、全員の作業項目がイテレーションごとの全体的な話し合いに含まれるようにするためです。チーム・メンバーは製品所有者と話し合って調整し、やるべきことを完全に把握してからイテレーションに取り掛かります。