プロダクト バックログの構築と管理
Mitch Lacey 著。 アジャイルとスクラムの導入と改善に特化したコンサルティング会社である Mitch Lacey & Associates, Inc の経営者です。
2012 年 1 月
この記事では、Mitch Lacey がプロダクト バックログの重要性について説明します。優れたバックログに必要な作業や、バックログの作成および維持のためのベスト プラクティスについて説明します。
対象
アプリケーション ライフサイクル管理; Team Foundation Server (TFS)
この記事の内容:
はじめに
プロダクト バックログ
ユーザー ストーリー
見積もり
優先順位付け
常に変化するプロダクト バックログ
- グルーミング
プロダクト バックログは、プロジェクトを完了するために必要なすべての機能が優先順位付けされたリストです。 TFS では、作業項目を使用してプロダクト バックログを管理します。 作業項目の種類の選択は、チーム プロジェクトの作成に使用したプロセス テンプレートによって異なります。 プロセス テンプレートおよびそこでサポートされる作業項目の種類の詳細については、「チーム プロジェクト成果物の操作、プロセス テンプレートの選択」を参照してください。
優れたプロダクト バックログはアジャイル チームが正常に機能するための中心的な要素であり、次の特性があります。
チームが最も重要な機能から先に構築できるように優先順位が付けられています。
チームが見積もりを行うことで、製品所有者は状況を明確に把握し、ストーリーの完了時期などに関する質問に回答できます。
プロジェクトを完了するために必要なすべての作業が含まれています。
プロジェクトの現状が反映され、常に変化し、進化する、動的なドキュメントです。
優れたプロダクト バックログがあっても、必ずしも優れたソフトウェアが構築されるわけではありません。 ただし、優れたプロダクト バックログがないと、結果として顧客や利害関係者の要件を満たさない不完全なソフトウェアが構築されることは少なくありません。
プロダクト バックログの管理は専任の作業です。 簡単な手法によって、煩雑で時間がかかるプロセスを、チーム メンバー、顧客および利害関係者が効率的に関与できる対話的で反復的なプロセスに変えることができます。 したがって、プロダクト バックログの構築、優先順位付け、および維持に役立つ確実な手法を習得することが不可欠です。
プロダクト バックログ
プロダクト バックログは、プロジェクトを完了するために必要なすべての機能が優先順位付けされた常に変化するマスター リストです。 プロダクト バックログには、通常は、要件のユーザー ストーリー ( 要件など)、バグ、調査タスク (スパイク) および技術的改善点が含まれます。 これらの項目は、通常ストーリー ポイントと呼ばれる、抽象的な単位で見積もります。
プロダクト バックログには、プロジェクトに必要なすべての作業が含まれており、時間の経過に伴って進化します。 したがって、プロダクトの新機能だけでなく、バグ修正や調査など、チームの時間を要するあらゆる作業が含まれます。 チームが行う作業は、すべてプロダクト バックログに含める必要があります。これは、プロジェクトの玄関口となるものです。 プロダクト バックログにすべての作業が含まれていれば、製品所有者、チーム、および管理者は、残りの作業をより明確に把握することができ、最終段階での予期しない問題の発生を削減できます。
プロジェクトの開始時点では、見積もりや優先順位付けの準備が整った、適切に定義された完全なプロダクト バックログ項目は用意されていることは稀です。 多くの場合、手元にあるのは、ストーリーをメモしたカードや、いくつかの機能仕様です。 この無秩序な状況を整理して、チームがバックログの見積もりを開始できるようにするのは、製品所有者の仕事です。
ユーザー ストーリー
最初の手順として、すべてのアイデアやメモをユーザー ストーリーに変換します。これは、エンド ユーザーが求める機能 (ソフトウェアが実行する必要のある機能) を表現するもので、実装の詳細 (これらの要件を満たすソフトウェアを作成する方法) ではありません。 各ユーザー ストーリーのタイトルは、"<ユーザー> として、<理由> のために <機能> が必要です" という形式に従う必要があります。
.png "ストーリー カードの例")
プロダクト バックログ自体と同様、各ユーザー ストーリーも時間の経過に伴って進化します。 プロジェクトの期間全体にわたって、チームはこれらのストーリーの優先順位付けと見積もり、ストーリーの詳細情報の追加、より小さなストーリーへの分割、またはストーリーの完全な削除などの作業を行います。 スプリントに含められたものは実装され、顧客に提供されます。
ユーザー ストーリーの詳細については、「バックログの作成」および「PowerPoint を使用したアイデアのストーリーボード」を参照してください。
すべてのアイデアやメモをユーザー ストーリーに変換したら、次は見積もりと優先順位付けを行います。
見積もり
定義上、見積もりは厳密なものではありません。 ただし、時間と実践を積み重ね、チーム全体が参加することで、当初と比較して正確な見積もりを作成できるようになります。最初の手順では、チームを招集し、プロダクト バックログ項目の見積もりを行います。 各ストーリーを見積もるときには、チームはストーリー ポイントと呼ばれる抽象的な測定単位を使用して、相対的なサイズの見積もりを作成します。
見積もりは次の 2 つの理由で不可欠です。
"いつ終了するか" という質問に答えるために役立ちます。
製品所有者が各項目の優先順位を決定するのに役立ちます。
見積もりによって、製品所有者とチームは特定のストーリーのコストを把握できます。そのため、製品所有者は各ストーリーに相対的な優先順位を付けることができます。 項目の見積もりが大きいほど、時間やリソースの点でその実装コストは高くなります。 このため、製品所有者のウィッシュ リストで優先順位が高かった項目でも、コストが高いと優先順位が低下する可能性があります。
チームは、プランニング ポーカー、ビッグ ウォール、または他の手法を使用して、ストーリー ポイントによる作業の見積もりを行うことができます。 見積もりの手法およびストーリー ポイントの簡単な説明については、「見積もり」および「バックログのグルーミングと見積り」を参照してください。
チームがすべてのストーリーの見積もりが完了したら、次は優先順位を付けます。
優先順位付け
すべてのプロダクト バックログは、ビジネス価値とリスクの観点から優先順位が付けられます。 製品所有者は、バックログの各項目を他の項目と比較して、相対的な優先順位を決定します。 このことを行うために、製品所有者は各項目のサイズ、ビジネスに対する価値、および関連するあらゆるリスクを検討します。 その後、各項目は優先順位の降順に並べ替えられます。 優先順位の高い項目はプロダクト バックログの上部またはその付近に示され、優先順位の低い項目は下部またはその付近に示されます。 チームは、最も重要な項目が最初に完了するように、最も優先順位の高い項目の中から次のスプリントの作業を選択します。
バックログ内の各項目のサイズは同じであるとは限りません。 1 つのスプリントで完了できる項目もあれば、大きすぎてチームが作業内容や実装にかかる時間を厳密に把握できない項目もあります。 これは問題ありません。 項目がバックログの上部に近づくにつれ、次のスプリントで対処する作業をチーム全員がより的確に把握できるように、チームはそれらを細分化して明確にします。
見積もりと同様、初期プロダクト バックログの優先順位付けは困難な場合があります。 最終成果物、リスク、コストを考慮しながら、競合する利害関係者の要求のバランスを効果的に保つにはどうすればよいでしょうか。 このような場合のために、イノベーション ゲームや相対的な重み付けなど、タスクを容易にするいくつかの手法が存在します。 これらの手法やその他の手法の詳細については、「優先順位付け」および「バックログのグルーミングと見積り」を参照してください。
どのような優先順位付け手法を選択しても、ビジネス、利害関係者、および顧客に最大の価値を提供する機能をチームが確実に構築できるように、作業の順序を決める必要があります。 作業に優先順位を付けないと、優先順位の高いユーザー ストーリーではなく低いユーザー ストーリーを提供し、リソースやスケジュールの変更があった場合に不完全なユーザー ストーリーを提供するリスクが高くなります。
(バックログ項目の特性の詳細については、「バックログの作成」および「ポートフォリオ バックログの使用」を参照してください)。
常に変化するプロダクト バックログ
これまでは、プロダクト バックログの見積もりと優先順位付けをゼロから始める作業について重点的に説明しました。 要件ドキュメントとは異なり、プロダクト バックログはプロジェクトの最初に作成して棚にしまっておくものではありません。 プロダクト バックログは進化し、プロジェクトの実情に合わせて拡大、縮小します。 プロダクト バックログ項目の中には、関連性がなくなり、削除が必要となるものがあります。 また、優先順位が上がり、小さいストーリーに分割する必要があるものもあります。 追加の要件が発生すると、新しいユーザー ストーリーが追加され、見積もりと優先順位付けが行われます。
チームと利害関係者はプロダクト バックログの作成と管理に関与しますが、製品所有者がその最終的な責任を負います。 製品所有者は、顧客とチームの両方がプロジェクト リリースに向けた作業計画を明確に把握できるように、バックログが完全であり、優先順位が付けられた最新の状態であることを保証する必要があります。 プロジェクトの最中でも、製品所有者はプロダクト バックログの状態を保つために多くの作業を行います。
新しいストーリーを追加して優先順位を付ける
新しいストーリーの見積もりと、より正確に把握できるようになった古いストーリーの再見積もりをチームに依頼する
次の作業対象ストーリーをチームと共に確認し、必要に応じて項目を分割する
顧客や利害関係者と協議して、要件を確認および追加する
プロダクト バックログへの項目の追加は、だれでも随時行うことができますが、優先順位を付けることができるのは製品所有者のみです。 また、ストーリーへの優先順位の割り当てができるのも製品の所有者のみです。 チームの他のすべてのメンバーと利害関係者は、優先順位情報の入力が求められる電子ツールを使用している場合でも、ストーリーを追加するときに優先順位を空白にする必要があります。
ストーリーが追加されると、製品所有者は自分の理解に基づいて優先順位を暫定的に評価します。 製品所有者はストーリーについて作成者と協議し、チームからの質問に回答できるように理解を深めます。 各スプリントのあらかじめ決められた時間で、製品所有者は新しいストーリーについてチームと協議し、バックログの他のストーリーに対してより正確な優先順位付けができるように、ストーリーを共同で見積もります。 このプロセスは、バックログのグルーミングと呼ばれます。
グルーミング
前に述べたように、プロダクト バックログのグルーミングは定期的に行う必要があります。
スクラムでは、チームは各スプリントの 5% ～ 15% の時間をグルーミング作業に費やす必要があります。 優先順位が上昇している大きいストーリーの分割、作成されたストーリーの見積もり、および今後ののストーリー向けの緊急の設計や計画を可能にするために、チームは直近の見通しや現在どのような変化が起きているかを把握しておく必要があります。 このことが確実に実現されるように、製品所有者とチームは各スプリント計画会議で、そのスプリント中にバックログのグルーミングを協力して行う時間を確保する必要があります。 スプリント計画の詳細については、「スプリント計画」および「スプリントでの作業」を参照してください。
2 週間のスプリント中、この会議は第 2 週に開催することをお勧めします。 これにより、製品所有者は十分な時間をかけて顧客や利害関係者との有意義な話し合いを行い、ビジネスの変化を把握し、ユーザー ストーリーや新規または優先順位が上昇しているストーリーを明確にすることができます。 また、スプリント期間中に次のスプリントの準備を開始するのも理にかなっています。 会議の開催日時は、任意に決定できます。 重要なことは、スプリント期間中にグルーミング作業を完了するための十分な時間を確保することです。
通常のグルーミング会議では、製品所有者は最新の状況や変化のあった状況について示し、今後のいくつかのスプリントに対する自分の計画を提示します。 新しいストーリーの見積もりや早く完了する必要のあるストーリーの分割以外に、チームは、この会議で、システムの現在のアーキテクチャを確認し、次に実現する機能の計画や設計を行います。 このプロセスでは、ストーリーの見積もりが頻繁に変更されます。新しいストーリーは大きいストーリーとして出現し、小さいストーリーに分割される傾向があります。
このプロセスは単純に見えますが、若干困難な場合があります。 プロセスを円滑に進めるため、製品所有者は質問への回答を準備しておく必要があります。 たとえば、製品所有者が次のスプリントで行うストーリーを計画していても、明確さが不足し、チームが適切に見積もることができない場合は、議論が生じることがあります。 スプリント計画会議でこのような事態が発生した場合、スクラム マスターは、顧客や利害関係者からのどのような情報を製品所有者がチームに提示する必要があるかについて、製品所有者にアドバイスする必要があります。
各グルーミング会議の終了時、製品所有者は現在の状況、直近の見通し、更新済みのリリース計画について全員が把握できるように、利害関係者および顧客に変更点を提示する必要があります。
優れたプロダクト バックログは、顧客や利害関係者との話し合いで特定され、ユーザー ストーリーで定義された最も重要な機能を、構築するソフトウェアに確実に組み込むために役立ちます。 優れたプロダクト バックログを作成し、維持するには、利害関係者や顧客のグループとチームとの積極的な交流を定期的に (つまり各スプリントで) 行う必要があります。
優れたバックログによって優れたシステムが保証されるわけではありませんが、優れたバックログがない場合は、最終的に顧客の要求する機能が実行されないシステムとなることがほとんどです。 つまり、バックログを最新の状態に維持しないと、ほとんどの場合にプロジェクトは失敗します。
製品所有者は専任の業務であり、バックログの責任者です。 この役割は非常に重要です。 プロダクト バックログを適切に維持することは、顧客満足につながります。
参照
概念
Visual Studio ALM および TFS での作業の追跡