効果的な製品バックログの作成
チームでは、顧客が求めることや重視することを表す製品バックログを作成します。製品バックログには、通常、ユーザー ストーリーが含まれます。 プロジェクトの期間全体にわたって、チームは、ユーザー ストーリーへの詳細情報の追加、ユーザー ストーリーより小さなストーリーへの分解、ストーリーの優先度付けおよび見積もり、ユーザー ストーリーの実装、顧客への結果の提供などの作業を行います。 優れたユーザー ストーリーを作成し、製品バックログを絶えず更新することによって、より効果的に顧客に価値を提供できます。
Bill Wake 氏は、効果的なユーザー ストーリーを作成するうえで重要となる要素を表すために、INVEST (independent (独立している)、negotiable (交渉可能)、valuable (価値がある)、estimable (見積もり可能)、small (小さい)、testable (テスト可能)) という頭字語を使用しています。 詳細については、「XPlorations」の Web サイトを参照してください。 Mike Cohn 氏は、著書の中でユーザー ストーリーの書き方について触れています。該当する章は、「User Stories Applied for Agile Software Development (ユーザー ストーリーをアジャイル ソフトウェア開発に活かす)」の Web サイトからダウンロードできます。
チームでユーザー ストーリーを作成する場合は、次の質問に回答する形で、顧客の価値をユーザー ストーリーに反映します。
ユーザーはだれか
ユーザーは何をする必要があるか
ユーザーはなぜそれをする必要があるか
ほとんどの場合は、これらの質問の回答を効果的なタイトルにまとめることができます。 Mike Cohn 氏は、"私は、<ユーザー> として、<理由> を実行する目的で <行動> する必要がある" という形式を推奨しています。 "私は、顧客サポート担当者として、顧客からの質問に迅速に対応できるようにする目的で、顧客情報にアクセスする必要がある" は、その一例です。 多くの場合、理由は明白です。 たとえば、"私は、菜食主義者として、菜食主義者用の食事だけが表示されるようにビューをフィルター処理することができる" という例でも、理由は明白です。
また、ユーザー ストーリーは、順序を問わず実装できるように定義する必要があります。 ただし、ユーザー ストーリーを完全に独立させるのは必ずしも実用的ではありません。 Bill Wake と Mike Cohn の両氏は、独立したユーザー ストーリーを作成するのが困難な場合にチームが使用できる手法について書いています。
価値があり独立したユーザー ストーリーは、既に述べたように、製品バックログを構成します。 チームは、ユーザー ストーリーの見積もりと優先度付けを行った後、最も順位の高いユーザー ストーリーから作業を開始します。 チームで実装するユーザー ストーリーは、次のリストに示す特性を備えている必要があります。 製品所有者は、スプリント計画会議にかける前に、順位が最も高いユーザー ストーリーがこれらの基準を満たしていることを確認します。
スプリントで実装できる程度に小さいこと。
実装するユーザー ストーリーは、スプリントで完成させることができる程度に小さい必要があります。 ユーザー ストーリーが大きすぎる場合、製品所有者がチームと協力してユーザー ストーリーを分解します。 たとえば、"私は、顧客サポート担当者として、顧客からの質問に迅速に対応できるようにする目的で、顧客情報にアクセスする必要がある" というユーザー ストーリーは、スプリントで完成させるには大きすぎます。 このユーザー ストーリーは、"私は、顧客サポート担当者として、顧客の電話番号を使用して、顧客の名前と最新の簡略コール記録にアクセスする必要がある" と "私は、顧客サポート担当として、現在の問題をより綿密に調査する目的で、顧客の完全なコール履歴にアクセスする必要がある" に分解できます。
ストーリーを実装するうえで必要な作業の記述および見積もりを行うことができる程度に詳細であること。
ユーザー ストーリーをスプリントに含める前に、ストーリー ポイントの単位でユーザー ストーリーを見積もります。 バックログの管理とスプリントの準備に使用するために、これは、あえて大まかな見積もりにします。 スプリントが始まったら、チームは、ユーザー ストーリーを、実装に必要なタスクに分解します。 チームは、製品所有者の協力の下に、製品バックログのグルーミング会議において、どのストーリーに関して、タスクに分解して作業時間数を見積もるためにより詳細な情報であるかを見極めます。 製品所有者は、必要な詳細情報を収集し、それをユーザー ストーリーの説明に記録します。
ここで、必要以上に詳細な情報をユーザー ストーリーに追加しないように注意してください。 このユーザー ストーリーは、ユーザー ストーリーが完成して承認されるまで続く製品所有者および顧客との会話および交渉の土台になります。 必要以上に詳細な情報を使用すると、正確ではない細部が暗示されるため、交渉の妨げになります。
承認基準の定義。
スプリントの最後に、顧客または製品所有者は、ユーザー ストーリーを完成と見なして承認するか、または拒否します。 スプリントを開始する前に、顧客の承認基準をできる限り明確に記述しておく必要があります。 当然のことながら、予想外の理由でユーザー ストーリーが承認されないこともあります。 ただし、承認基準を定義するためにチームと顧客との間で行われた会話は、顧客が期待している内容をチームが理解するうえで役に立ちます。 承認基準は承認テストの土台として使用できるため、ユーザー ストーリーを完成させることができたかどうかをより効果的に評価できます。
エピックとテーマ
ユーザー ストーリーは小さくあるべきだとよく言われます。 これは、実装しようとしているユーザー ストーリーに対して当てはまります。 ただし、順位が下位のストーリーは大きくてもかまいません。 実際、このようなストーリーを大きいままに保つことは、管理の面から製品バックログが大きくなりすぎるのを防ぐ意味で良い方法です。 優先度が付けられた製品バックログの上部に近いユーザー ストーリーほど、より小さなユーザー ストーリーに分解できます。 大きなユーザー ストーリーは、エピックとテーマと考えることができます。
エピックとは、大量の作業を表す非常に大きなユーザー ストーリーです。 エピックを分解すると、多くのテーマとその他の小さなユーザー ストーリーを作成できます。
テーマは、通常はスプリントで実装するよりもかなり大きなユーザー ストーリーです。 テーマを実装する前に、より小さなユーザー ストーリーに分解する必要があります。
製品バックログの優先度を付ける場合は、上部に近いエピックとテーマを分解し、新しい小さなユーザー ストーリーに対して優先度付けを行います。 作業が終了した段階で、優先度が最も高いユーザー ストーリーは、実装できる程度に小さいことが求められます。 ほとんどの場合、優先度が付けられたバックログの下部にあるユーザー ストーリーは大きくなります。
スパイク
ユーザー ストーリーの直接の実装ではない作業をチームで行うことが必要になる場合があります。 この作業はスパイクと呼ばれます。 通常、スパイクには、調査、バグ負債、およびプロセスまたはエンジニアリングの改良の 3 種類があります。 Team Foundation でスパイクを作成するには、ユーザー ストーリー作業項目を作成し、スパイクの種類を設定します。次に、製品バックログで他のユーザー ストーリーと共に優先度付けを行います。
調査
調査は、タスクへの分解と見積もりを行うために必要な回答がまだ得られていないユーザー ストーリーに関する質問がある場合に行います。 たとえば、チームは、スプリント計画会議において、"私は、飛行機を頻繁に利用する客として、特典の旅行を予約できる" というストーリーがあるとします。 これについて検討した結果、回答よりも多くの質問が出されました。 そこで、チームは、スパイクを表すユーザー ストーリーを作成します。 " 私は、チーム メンバーとして、'特典の旅行を予約' が意味することを理解できる。したがって、私は、将来のスプリントに含めるストーリーを記述することができる"。 チームは、この調査に費やす時間数を決定し、その数字をスパイクの時間枠に書き込みます。 スパイクの期間中に記述されたいずれのストーリーも、このイテレーション中に実行することはできません。 作業は、製品バックログを使用して将来のイテレーション用にスケジュールする必要があります。
バグ負債
バグを修復するのに最適なタイミングは、バグを見つけたときです。 バグを見つけた当日にそのバグを修復できない場合は、忘れないようにバグ作業項目を作成する必要があります。 バグをため込まないように注意してください。 バグがたまった場合は、ユーザー ストーリーを作成し、バグをスパイクにリンクして、他のユーザー ストーリーおよびスパイクと共に見積もりと優先度付けを行うことができるようにします。
プロセスまたはエンジニアリングの改良
チームは、成功を目指してプロセスまたはエンジニアリングの改良を行います。 通常、改良の余地がある点は、スプリント振り返り会議および毎日のスクラム会議で確認します。 たとえば、場合によっては、単体テストでコード カバレッジを改良したり、継続的インテグレーション サーバー上でビルド時間を短縮したりする必要があります。