プロダクトバックログ: 究極の行動リスト

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

Dan Radigan Dan Radigan
Browse topics

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

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

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

プロからのヒント:

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

2 つの「R」から始める

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

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

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

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

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

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

プロダクト所有者の優先順位付けに影響する要素

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

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

バックログの健全性の維持

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

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

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

プロからのヒント:

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

次の逆パターンに注意しましょう

  • プロダクト所有者はプロジェクト開始時に優先順位付けをするが、開発者や関係者からフィードバックを受けても優先順位を調整しない。
  • チームはバックログへの記載を対顧客項目に限定する。
  • バックログはローカルに保存され、共有されるのは稀であるため、関連当事者に更新情報が伝わらない。

プロダクトバックログを活用してアジャイルを実現するには?

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

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

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

プロからのヒント:

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