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