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

アジャイルバックログの優先順位が適切に設定されていると、リリースやイテレーション計画が容易になるだけではなく、顧客が知ることのない内部作業を含むあらゆるチーム活動を全体が把握できます。利害関係者や他のチームは予測を立てやすくなり (特に追加作業を依頼するとき)、エンジニアリング期間を固定できます。

A product backlog is a prioritized list of work for the development team that is derived from the product roadmap and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first. The development team doesn't work through the backlog at the product owner's pace and the product owner isn't pushing work to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it, either continually (kanban) or by iteration (scrum).

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

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

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

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

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

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

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

バックログが大きくなったら、プロダクトオーナーがバックログを短期目標と長期目標にグループ分けします。グループ分けをする前に、短期目標を完全に具体化する必要があります。つまり、完全なユーザーストーリーを作成し、設計および開発チームとのコラボレーション体制を整え、開発チームから見積もりを受け取ります。長期目標には少し曖昧さが残ってもかまいませんが、優先順位を設定するために開発チームから大体の見積もりを受け取っておくとよいでしょう。重要なのは「大体の」という点です。 チームが長期目標を完全に把握して取り掛かる時点で、見積もりに変更が生じるからです。

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

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

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

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

利害関係者が優先順位に異議を申し立てることもあります。これは好ましいことです。何が重要かについて話し合うことで、全員が共通の認識を持つことができます。このような話し合いを通じてグループの優先順位を設定する文化が育まれ、全員がプログラムについて同じ考え方を共有できます。

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