製品バックログ: 作成と優先順位付けのヒント

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

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

スクラムのフレームワークでは、スクラム製品バックログは、開発チームのタスクを決定するためにスクラム製品所有者が使用する、入念に作成された構造化リストです。

Jira スクラム・ボードを試す

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

製品バックログを適切に管理することは、開発チームに多くのメリットをもたらします。そのメリットをいくつかご紹介します。

• 優先順位付けの改善: 最も重要なタスクを最初に処理できます。
• 効率の向上: 顧客からのフィードバックとビジネス目標に基づいてタスクに優先順位を付けることで、最も価値のあるタスクに確実に取り組むことができます。
• より良いコミュニケーション: 全員が足並みを揃え、同じ目標に向かって取り組むことができます。
• 無駄の削減: 顧客からのフィードバックとビジネス目標に基づいてタスクに優先順位を付けることで、無駄を減らし、価値のないタスクには取り組まないようにすることができます。
• 顧客満足度の向上: 顧客からのフィードバックに基づいてタスクに優先順位を付けることで、顧客が望む機能を確実に提供できます。

全体として、アジャイルな製品開発では、製品バックログを適切に管理することが不可欠です。これにより、最も価値のあるタスクに取り組み、全員が足並みを揃えて同じ目標に向かって取り組むことができます。

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

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

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

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

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

製品バックログに効果的に優先順位を付けることで、最も重要なタスクに最初に取り組み、チームの自律性と製品所有者の要求とのバランスを取ることができます。

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

製品バックログの作成は、アジャイル製品開発における重要なステップです。このステップには、製品ロードマップの作成、製品バックログ項目のリストアップ、チームとのコミュニケーションが必要です。

製品ロードマップは、製品のビジョン、目的、目標を定義する大まかな計画です。製品ロードマップに基づいて製品バックログを作成することで、全員が足並みを揃えて同じ目的に向かって取り組むことができます。

製品ロードマップを作成するには、製品のビジョンとミッションを定義します。次に、達成すべき主要な目標と目的を特定します。最後に、目標を製品バックログに追加できる小さくて管理しやすいタスクに分解します。

製品ロードマップが作成できたら、製品バックログ項目をリストアップします。これらの項目には、機能、ユーザー ストーリー、バグ、設計変更、技術的負債などが含まれます。

製品バックログ項目をリストアップするときは、各項目の明確な説明と、推定時間や必要なリソースなどの関連情報を記載しましょう。また、顧客からのフィードバック、要求、ビジネス目標に基づいて項目に優先順位を付けることも重要です。これにより、開発チームは最大の価値をもたらすタスクに取り組むことができます。

製品バックログを作成するときは、効果的なコミュニケーションが不可欠です。製品所有者は開発チームと緊密に連携して、全員が製品バックログと優先事項を理解できるようにする必要があります。また、営業やマーケティングなどの他のチームともコミュニケーションを取り、全員が足並みを揃えて同じ目的に向かって取り組んでいることを確認する必要があります。

定期的に会議を行ったり最新情報を提供したりすることで、全員が同じ認識を持ち、製品バックログを効果的に管理できます。

より詳しいガイダンスが必要な場合は、Jira の製品バックログ テンプレート (無料) をお試しください。

開発チームが最大の効果をもたらすタスクに集中できるようにするには、バックログの優先順位付けが不可欠です。次のような方法があります。

MoScoW や加重スコアリングなどのさまざまなバックログ優先順位付け手法は、タスクを効果的に管理し、順序付けるのに役立ちます。優先順位付けのプロセスには、変化の激しいビジネス環境に適応するために定期的に目標を見直し、再調整することが含まれます。

• ユーザーにとって最も価値の高い機能や修正を特定します。
• 顧客からのフィードバック、アンケート、または分析を使用して、優先順位を特定します。

• チームや関係者にアクションにつながるインサイトをもたらす項目を優先します。
• たとえば、新機能を早期にテストすることで、後で時間とリソースを節約できます。

• 短期間で完了できる作業とより複雑で長期的なプロジェクトを含めることで、バックログのバランスを取ります。
• 資源を賢く使用するために、労力と成果の比率を比較検討します。

• 他の人が作業を行うための前提となるタスクを特定します。
• 基礎的な作業を最初に行うと、ワークフローが合理化されます。

バックログの優先順位付けをサポートする信頼できるツールがあれば、製品開発を合理化し、効率を高めることができます。製品所有者が優先順位付けを主導し、開発チーム、設計者、関係者を巻き込むことで、優先事項についての共通の理解が深まります。定期的に話し合うことで、意思統一が図られ、意思決定が改善されます。

ヒント: MosCOW (Must-have (必須)、Should-have (推奨)、Could-have (可能)、Won’t-have (先送り)) や加重スコアリングのような優先順位付けフレームワークを使用して、客観的でデータ主導の意思決定を行いましょう。Jira Product Discovery は柔軟な優先順位付け機能を備えており、独自の優先順位付けフレームワークの実装が可能です。

製品バックログを作成したら、それを維持して定期的にプログラムと歩調を合わせることが重要です。製品所有者はイテレーション計画ミーティングの前にバックログをレビューし、優先順位付けが適切で、前回のイテレーションからのフィードバックが反映されていることを確認する必要があります。このようなレビューは、アジャイルの世界では製品バックログ リファインメントとも呼ばれており、タスクが関係者のインサイトと一致していることを確認し、次のスプリントに向けてチームの準備を整えます (バックログ リファインメントという用語を使用することもあります)。

バックログが大きくなったら、製品所有者がバックログを短期目標と長期目標にグループ分けします。グループ分けをする前に、短期目標を完全に具体化する必要があります。つまり、完全なユーザー ストーリーを作成し、設計および開発チームとのコラボレーション体制を整え、開発チームから見積もりを受け取ります。

長期目標は曖昧でかまいませんが、優先順位を設定するために開発チームから大体の見積もりを受け取っておくとよいでしょう。重要なのは「大体の」という点です。チームが長期目標を完全に把握して作業を開始すると、見積もりに変更が生じるからです。

バックログは、製品所有者と開発チームの間をつなぐ役割を果たします。製品所有者は顧客からのフィードバック、見積もりの精緻化、新規要件をもとに、バックログでの作業の優先順位を自由に再設定できます。しかし、いったん作業が開始されたら、変更は最小限に抑えるべきです。開発チームの混乱を招き、集中力、フロー、士気に影響を与えるからです。

ヒント: バックログが増えすぎてチームの長期的な能力を超えた場合は、対応できそうにない課題をクローズしてかまいません。このように特定の決定を下した課題には、後で把握できるように、課題トラッカーで「対応範囲外」のようなフラグを付けておきましょう。

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

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

知識豊富な製品所有者は、プロジェクトの作業項目の信頼性が高く共有可能な概要を作成するために、プログラムの製品バックログを厳密に管理します。

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

適切に優先順位付けされたアジャイル バックログがあれば、何に時間をかけるべきかが明確になり、目に見える内部のタスクが浮き彫りになります。製品バックログは、イテレーション計画の基礎にもなります。バックログにはすべての作業項目を盛り込みます (ユーザー ストーリー、バグ、設計の変更、技術的負債、顧客からの要望、過去に遡ってのアクション アイテムなど)。これにより、全員の作業項目がイテレーションごとの全体的な話し合いに含まれます。チーム メンバーは製品所有者と話し合って調整し、やるべきことを完全に把握してからイテレーションに取り掛かります。

ヒント: バックログの作業項目の優先順位を決めるのは製品所有者ですが、そのベロシティを決めるのは開発チームです。作業を早く進めるよう指示したい新任の製品所有者にとっては、この関係はもどかしいかもしれません。この記事では、進行中の作業の制限とフローについて説明しています。