優れたユーザ ストーリーの作成

ユーザ ストーリーとは何か

ユーザ ストーリーは、チームがイテレーション内でもたらすことができるビジネス価値の小さな一片を示しています。従来の要件(ユース ケースなど)で可能な限り詳細に記述しようとするのに対し、ユーザ ストーリーは次の 3 つのステージで段階的に定義されます。

  • 必要なものの簡単な説明
  • 詳細を固めるための、バックログの改善およびイテレーション計画中の会話
  • ストーリーの十分な完了を確認するテスト

上手く形作られたストーリーは、Bill Wake の INVEST アクロニムの基準を満たします。

Independent(独立している) どのような順序でも開発できることが望ましい。
Negotiable(相談の余地がある) 詳しくしすぎることを避けます。柔軟にしておき、チームがストーリーのどれだけを遂行するか調整できるようにします。
Valuable(価値がある) ユーザまたは顧客がストーリーから価値を得る。
Estimatable(見積もりが可能) チームがそれらを計画で使用できることが必須です。
Small(小規模) 大規模なストーリーの場合、見積もりおよび計画がより困難になります。イテレーション計画時までに、ストーリーをイテレーション内で設計、コーディング、テストできるようにする必要があります。
Testable(テストできる) テスト ケースにつながる、ドキュメントの許容基準、またはストーリーの完了の定義。

ユーザ ストーリーを使用する理由

  • ビジネス価値を体現しつづける
  • 設計のオプションを阻み、1 つのソリューションに開発者を不適切にがんじがらめにする、早すぎる段階での詳細の導入を避ける
  • 間違った完全性および明確さが生じるのを避ける
  • 交渉やバックログ内の活動を誘因するのに十分な小さい塊を作る
  • アーキテクト、開発者、テスタなどに技術的な機能を任せる

ユーザ ストーリーの作成方法

ストーリーの作成を開始するときは、テンプレートを使用すると、うっかり技術的なタスクの記述を始めることを防ぐことができます。

<ユーザ タイプ> として、<メリット> のために <機能> がほしい。

  • 消費者として、オンラインでアイテムを簡単に購入するためにショッピング カート機能がほしい。
  • エグゼクティブとして、どの部門が生産性を向上させる必要があるのか理解するためにレポートを生成したい。

ユーザ ストーリーを作成する場合、ユーザという汎用のロールはなるべく避けるようにしてください。ユーザ ストーリーはシステムと通信する、または価値や利益をシステムから作り出しているすべてのロールに関係します。エンド ユーザ以外のアクターもいます。たとえば、他のシステムもロールになり、製品を購入するために特定の機能を欲していて、しかし実際にはその製品を使用しない人もロールになります。集合ロール(消費者など)および分化したロール(参照者、よく買い物する人など)を作成すると便利かもしれません。

CA Agile Central では、このテンプレートは[説明]フィールドの上部に入力する必要があります。これは、下に入力される詳細および許容基準の基調を定めます。

ユーザ ストーリーはどのようなサイズにする必要があるか

ストーリーは、イテレーション内で、理想的には 2、3 日でコーディングおよびテストできるくらい小さくする必要があります。ストーリーが大きすぎる場合、それはエピックと呼ばれています。バックログ項目は、優先順位が低い場合、エピックとして開始される傾向があります。リリース計画の場合は、エピックは小さい塊に分解する必要がありますが、詳細設計に移したものほど小さくする必要はありません。

ユーザ ストーリーはどのくらい詳しくする必要があるか

大まかすぎる例

 

  • チーム メンバーがイテレーションのステータスを表示できる。

詳しすぎる例

  • チーム メンバーが、ランク、名前、サイズ、パッケージ、所有者、ステータスが記載されたストーリーの表を表示できる。
  • チーム メンバーが赤のボタンをクリックして、すべてのタスクをランク、名前、見積もり、所有者、ステータス付きでリストしている、詳細を含む表を展開できる。

ちょうどいい例

  • チーム メンバーがイテレーションのストーリーと、そのステータスを主要なフィールドと共に表示できる。
  • チーム メンバーがステータス ページで現在のバーンダウン グラフを表示することができ、クリックして表示の大きさを広げられる。
  • チーム メンバーが、ストーリー下のタスクを表示できる、または非表示にできる。
  • チーム メンバーがイテレーションのステータス ページからタスクを編集できる。

詳細を追加するときはいつか

許容基準は、ストーリーの完了の定義を規定します。ストーリーの詳細は変化するため、許容基準として重要なものを理解します。プロダクト オーナーは、ストーリーの目的を明確にするため、できる限りたくさんの許容基準をリストする必要があります。許容基準がどのくらい詳細なものかに関係なく、チームはそれらについて話し合い、ディスカッションの結果を得るために許容基準を調整する必要があります。イテレーションが開始されると、テスタは許容基準を、許容テストとして正式なものにできます。

CA Agile Central で、許容基準を[説明]フィールドのバリュー ステートメントの下に直接配置します。デリバリ チーム メンバーには、この方法でストーリー情報のすべてを表示する場所が 1 つあります。箇条書きを使用すると、各基準項目を簡単および明快にしておくことができます。

ユーザ ストーリーを使用するのは誰か

作成: 顧客、顧客プロキシ、プロダクト オーナー、および製品に対してのニーズを見いだす誰でもがユーザ ストーリーを寄稿できます。
所有権と管理: プロダクト オーナーがユーザ ストーリーを所有し、書き込み、収集、維持、優先順位決定に対する責任を負います。
使用: 開発者、テスタ、テクニカル ライターが、何を遂行すべきか、およびそれがいつ完了するかを把握するためにユーザ ストーリーを使用します。プロダクト オーナーは、ユーザ ストーリーのステータスに基づいた全体の進行状況を追跡します。経営管理者は、エピックまたは特集にロールアップされたユーザ ストーリーを追跡する傾向があります。

よくある間違い

  • フォーマルすぎる、または詳しすぎる。 プロダクト オーナーは、善意からものすごく細かいユーザ ストーリーを書こうとすることがよくあります。 チームがイテレーション計画において IEEE 要件のドキュメントのようなストーリーを見ると、すべての詳細がそこに含まれていると思い込んでしまうことがよくあり、細部にわたる話し合いをスキップしてしまいます。
  • ストーリーのふりをしたテクニカル タスク。 アジャイルのパワーの多くは、各イテレーションの最後にソフトウェアの実用的な増強を得ることから生じています。 ストーリーが実は単なるテクニカル タスクである場合、各イテレーションの最後に実用的なソフトウェアを実現できることはあまりなく、優先順位決定での柔軟性を失います。
  • 話し合いをスキップする。ストーリーは、イテレーション計画の前は意図的に曖昧にされています。 許容基準についての話し合いをスキップすると、間違った方向へ進んだり、エッジ ケースを見逃したり、顧客のニーズを見落としたりするおそれがあります。

以下は、CA Agile Central のユーザ ストーリーのサンプルです。このストーリーは、バックログで上位に移動するにつれて、いくつかの改善および計画のミーティングでチームによって議論されており、もうすぐイテレーションにスケジュールされようとしています。このユーザ ストーリーの目的は、オンライン サイトにおける購入者がクレジット カードを支払いに使用できるようにすることです。

関連トピック

 

フィードバック

ヘルプをお求めですか?CA Agile Central コミュニティは、セルフサービスとサポートのワンストップ ショップです。CA Agile Central サポートにフィードバックを送信したり、答を見つけたり、他のユーザとのコラボレーションには CA Agile Central コミュニティ にご参加ください。