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

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

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

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

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

>> Ready to build a backlog? Try this interactive tutorial

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

2 つの「R」から始める

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

チームのロードマップは、プロダクトバックログの基礎を成すものです。

ロードマップの最初のイニシアチブは「Teams in Space」の Web サイトであるため、このイニシアチブをエピック (オレンジ) とユーザーストーリー (紫、黄、緑) に分割します。 

プロダクトオーナーは、ユーザーストーリーを開発チーム用の単一リストに編成します。

The product owner then organizes each of the user stories into a single list for the development team. The product owner may choose to deliver a complete epic first (left). Or, it may be more important to the program to test booking a discounted flight which requires stories from several epics (right). See both examples below. 

プロダクトオーナーはバックログに、ユーザーストーリーを1つの完全なエピックまたは複数のエピックとして編成できます。

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

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

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

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

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

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

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

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

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

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

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

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

バックログにより議論が促され選択肢ができ、プログラムの健全性が保たれる。すべてが最優先事項になる、といった事態にはならない。

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

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

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