INVESTの原則で効果的なユーザーストーリーを書く方法は？

ユーザーストーリーを作成するためのINVESTの原則

標準化されたフォーマットと完全な要素に加えて、優れたユーザーストーリーもINVESTの原則に従う必要があります。1。私は依存しています。2.交渉可能; 3.価値のある; 4.刺激可能; 5.Sモール; 6.テスト可能。

1.独立–1つのユーザーストーリーを他のユーザーストーリーから可能な限り独立させることが重要です。ユーザーストーリー間の独立性を維持することで、優先順位付けと調整が容易になるだけでなく、リリースと反復の計画が容易になり、独立した理解、追跡、実装、テスト、および頻繁な配信が容易になるだけでなく、ユーザーストーリーのサイズの見積もりの​​範囲が明確になり、見積もりの​​バイアスが高まります。小さい。

2.交渉可能–ユーザーストーリーの内容は交渉可能です。ユーザーストーリーは契約ではありません。ユーザーストーリーは、ユーザーストーリーの簡単な説明であり、詳細はあまりありません。具体的な詳細は、コミュニケーションフェーズで作成されます。詳細が多すぎるユーザーストーリーは、実際にはユーザー、チームのアイデア、コミュニケーションを制限します。

3.価値がある–各ストーリーは、顧客にとって価値がある必要があります（ユーザー、バイヤー、または社内の役割のいずれであっても）。ユーザーストーリーはエンドユーザーにとって価値があるため、タスクではなく機能を説明する、ユーザーの観点から作成する必要があります。

この機能により、チームの開発およびテストメンバーにとって、従来のディレクティブベースのワークスタイルから自己主導の価値指向のワークスタイルへの移行が容易になり、チームの全員が毎日行う作業の価値を知ることができます。

4.推定可能（評価可能）–計画会議で非常に重要な部分は、ストーリーポイントの推定です。これは実際には、チームがこのユーザーストーリーの複雑さ（作業負荷）を知ることができるように開発されるユーザーストーリーの大まかな見積もりです。

ユーザーストーリーの受信条件とチームが定義したDoD（完了基準）に従って、現在のイテレーションでユーザーストーリーを完了できるかどうかに焦点が当てられ、完了できない場合は、理由とPOが示されます。ユーザーストーリーを分割するか再設計するかを決定します。

開発者がストーリーを推定するのを困難にする問題は、ドメインに関する知識の欠如（この場合、より多くのコミュニケーションが必要）、またはストーリーが大きすぎる（この場合、より小さな断片に分割する必要がある）ことに起因します。

5.小さい–少なくとも1回の反復で確実に完了するために、ワークロードの観点から、良いストーリーはできるだけ短くする必要があります。できれば、1日あたり10人以下の理想的な人が必要です。ユーザーストーリーが大きいほど、スケジューリング、ワークロードの見積もりなどのリスクが高くなります。

6.テスト可能（テスト可能）–ユーザーストーリーは、完了できることを確認するためにテスト可能である必要があります。ユーザーストーリーがテスト可能でない場合、それがいつ完了するかを知ることはできません。テスト不可能なユーザーストーリーの例：ソフトウェアは使いやすいものでなければなりません。

3つのガイドライン

ユーザーストーリーは、INVESTの原則に従っている場合、基本的に優れたユーザーストーリーです。次に、ユーザーストーリーを作成する際の原則に準拠するために、3つのガイドラインに焦点を当てます。

3つのガイドラインは、1人のユーザー、完全な値、および依存関係なしです。

1. 1つのタイプのユーザー–複数のユーザーが微妙な違いを持っ​​ていることが多いため、1つのタイプのユーザーのみを含めます。これは通常、一般的なユーザーであり、多くの場合、ある種の一般的なニーズがあります。

2.完全な価値–顧客の価値全体を提供します。完全なユーザーストーリーとは、このストーリーが完了すると、ユーザーが明確で意味のある目標を達成できることを意味します。

3.非依存関係–依存関係の3つの一般的なタイプは、オーバーラップ、シーケンス、および包含です。

一般に、ストーリー間で機能ポイントが重複することは避けてください。連続した関係は現実であり、ほとんどの場合、何らかの手段で解決できます。包含関係は複雑なシステムに役立ち、注意が必要なリリースと反復計画のスケジューリングに影響します。

重複する依存関係

重複する依存関係は、特に複数のユーザーストーリーに複数の異なる重複する部分が含まれている場合に、最も問題を引き起こす依存関係の形式です。その最小限の実行可能な製品の機能のセットを表すことができるユーザーストーリーのセットを見つけることは困難です。これには、一度だけ必要な機能が含まれている必要があります。

解決

重複する部分を個別のユーザーストーリーとして取り除きます。
ユーザーストーリーを合理的に分割し、最もまとまりのあるユーザーストーリーの1つだけで重複を維持します。
スクラム開発モデルを使用します。

順次依存関係

シーケンシャル依存関係とは、ユーザーストーリーを完了するには、その前に1つ以上の他のユーザーストーリーを完了する必要があることを意味します。順次依存関係は通常無害であり、そのような依存関係を軽減する方法があります。

アジャイル開発の観点からは、システム全体が最初の最小実行可能製品から堅牢な製品に徐々に進化し、後の各ステップは前のステップに基づいて構築されます。

しかし、別の観点から見ると、不必要な順次依存関係により、ランク付けと優先順位付けがより困難になり、リリースおよび反復計画の開発に影響を与え、ユーザーストーリーのサイズを見積もることがより困難になります。

解決

イテレーション内のユーザーストーリーを、本質的な依存関係からできるだけ解放します。
反復間の一方向の依存関係のみを保持し、後の反復のストーリーから前の反復のストーリーまでの時間における一方向の依存関係のみを保持します（順方向の依存関係）。
コアの依存関係を個別のストーリーとして取り除き、依存要件と非依存要件を1つのストーリーに混在させないようにします。

依存関係の包含

含まれる依存関係とは、機能に複数のユーザーストーリーが含まれ、その下位のストーリーに対する機能の含まれる依存関係を構成する、一般的な2レベルの機能ストーリー管理などのユーザーストーリーの編成における階層管理の使用を指します。

解決

ユーザーストーリーレベルはイテレーション計画に使用され、リリース計画に使用できる機能レベルでの大まかなイテレーション計画を回避します。

機能レベルは、市場性のある最小限の機能のレベルになるまで分割することもでき、そこに含まれるユーザーストーリーは、新しく分割された機能に個別にグループ化できます。

最小限の実行可能な製品コンセプトに従って、機能は複数のユーザーストーリーの複数の反復で実装され、それぞれが潜在的な成果物をもたらしたり、内部または外部のフィードバックを提供したりする可能性があります。

 

参考文献

• 効果的なユーザーストーリー–3CおよびINVESTガイド
• テーマvsエピックvsユーザーストーリーvsタスク
• ユーザーストーリーマップ
• ユーザーストーリーマッピングとは何ですか？
• ユーザーストーリーのためのSMARTゴールと投資を書く