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

健全なプロダクトバックログとは、人間と同様に、
グルーミング (手入れ) が行き届き、整理され、オープンな状態にあるものを指します。

Dan Radigan 作成者 Dan Radigan
トピック一覧

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

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

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

プロからのヒント:

バグの追跡や要件、エンジニアリング作業項目を複数のシステムで管理するのではなく、1 つの課題トラッカーに集約しましょう。開発チームの作業をすべて 1 つのバックログで管理します。

2 つの「R」から始める

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

アジャイルロードマップ|アトラシアンアジャイルコーチ

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

アジャイルイニシアチブとエピック|アトラシアンアジャイルコーチ

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

アジャイルエピックとストーリー|アトラシアンアジャイルコーチ

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

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

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

製品バックログを効果的に管理する方法

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

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

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

プロからのヒント:

バックログの長期目標が増えすぎた場合、対応できそうにない課題をクローズしてかまいません。このような課題には、後で把握できるように、課題管理システムで「対応範囲外」のような個別対応フラグを付けておきましょう。

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

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

製品バックログを活用してチームのアジャイルを実現

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

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

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

プロからのヒント:

プロダクト所有者はバックログにある作業項目の優先順位を指示します。開発チームはバックログを通じてベロシティを決めます。チームに作業指示を出したい新任のプロダクト所有者にとっては、この関係はもどかしいかもしれません。詳細については、進行中の作業の制限とフローについての記事をご覧ください。

アジャイルの矢印

Jira のスクラム テンプレートで重要なことに優先順位を設定

実施すべき作業をすべて可視化することで、最大のインパクトを与える作業に集中できます。