ユーザーストーリーの準備

ユーザーストーリーは、エンドユーザーがアプリケーションをどのように使用したら特定の成果を達成できるかを説明しています。 これは人間を中心にして、ビジネス要件をシンプルで簡潔な形式で文書化したものです。 ユーザーストーリーは、アプリケーションで展開される作業の最小単位を表します。  

プロジェクトアーティファクトにとって、ユーザーストーリーの主な目的は、開発チームがクライアントのために開発し実装する必要のあるすべての機能を（プロジェクトバックログ内で）追跡できるようにすることです。 ユーザーストーリーでは、プロダクトオーナー、最終的にはエンドビジネスユーザーの満足度を高めるために機能の設計において何が必要となるかを説明しています。 チームは、チームの知識と経験を取りまとめ、ユーザーストーリーを作成します。 

ユーザーストーリーの主な特徴：

• 人間中心
• 理解しやすい
• クライアントが実現するビジネス価値が明確に反映されている
• テスト可能

ユーザーストーリーでは、まず2つの重要な要素を文書化します。 これらの要素により、ユーザーストーリーを完全に達成するために、何を開発する必要があり、どんな基準を満たす必要があるかが明確になります。   

2つの要素は次のとおりです。

• ユーザーストーリーの説明
• 合格基準 

また、各ユーザーストーリーにオプションで要素を追加し、添付ファイルやテクニカルノートで要件の詳細を明確にすることもできます。 

すべてのユーザーストーリーにはサイズとステータスが設定され、ストーリーの管理に役立ちます。 これらはユーザーストーリーの最初の形態から完了まで、ライフサイクルの進捗に合わせて更新されます。

ユーザーストーリーの説明の目的は、クライアントのビジネス要件を要約することです。 ユーザーストーリーの説明により、アプリケーションの特徴や機能を誰が必要としていて、何が必要で、なぜ必要なのかを確実に理解できます。 理解しやすいビジネス用語で書かれた短い文章にし、ビジネス価値を明確に示す必要があります。  

一般的なユーザーストーリーは、シンプルな文章形式で表現されます。

• ________ として［誰？ 　ユーザーを挿入］  
• ________ が欲しい［何？ 　やりたいことを挿入］
• ________ のために［なぜ？ 　ビジネス価値を挿入］

ユーザーストーリーの準備や話し合いは非常に重要です。  この集合的な理解は、対話によってのみ得られます。 集合的な理解を複雑なドキュメントに変換したいという誘惑に打ち勝つようにします。 ユーザーストーリーの本質に焦点を当て、詳細を添付ファイルで補足します。

次の例では、説明はユーザー、必要性、およびユーザーストーリーを導入するビジネス価値を明確に示すビジネス用語で書かれています。 また、簡潔な説明になっていることにお気づきになるかと思います。

合格基準では、ユーザーストーリーのリファインメントを行って、開発者がアプリケーションの実行内容を理解し、テスターが何をテストするかを明確にします。 プロダクトオーナー は、ユーザーストーリーから期待されるビジネスエクスペリエンスを定義し、合格基準を承認する必要があります。 ユーザーストーリーの合格基準は、ビジネス部門（および技術者ではないチームメンバー）が理解しやすい、曖昧な点のない言葉で書かれます。 

合格基準は開発チームに対する技術的な指示ではなく、成果として記述されます。 開発チームが業務チームと協力してソリューションを開発できるように、意図的に交渉可能とします。 合格基準は交渉可能ではあるとはいえ、テストできる程度に具体的な内容でなければなりません。 

次の例では、合格基準は具体的でテスト可能な成果として記述されています。

サンプルユーザーストーリーでは、合格基準を表現するための記述の例を示しています。 合格基準を文書化するには、シナリオベースの基準を把握するなど、他にもさまざまなスタイルがあります。 たとえば、チームは次のようにフォーマットされたGiven（前提）、When（条件）、Then（処理）のアプローチを選択できます。

• Given...{pre-condition} 例：「プレミアムメンバーが登録したとき...」
• When...{something is done} 例：「将来のプロモーションに自動的に登録され...」
• Then...{expected result} 例：「...メールを受け取ります」

プロジェクトの開始時に、チームは準備完了の定義（DoR）の意味を定義します。 チームは、準備フェーズの間にDoRに同意し、ユーザーストーリーの品質チェックのベースラインを設定します。 各プロジェクトで、チームの関連するビジネスチームおよび技術チームのステークホルダーがこれに合意します。 DoRには、ユーザーストーリーの作成前に満たしておくべき基準が記載されます。 DoRに沿ってユーザーストーリーが準備できたら、ストーリーをスプリント計画の対象としてマークできます。 

一般的に、DoRは基準のチェックリストになります。 基準にはストーリーに含める内容、実行するレビュープロセスやサインオフ、取得または添付が必要な出力などを定義します。 以下のスプレッドシートは、12の基準が含まれるサンプルユーザーストーリーを示しています。

事前に定義されたDoRで、チームメンバー全員がユーザーストーリーの最低必要条件を確実に理解できるようにします。 スプリントに組み込んだユーザーストーリーが品質チェックを経て、スプリントに正常に実装されることを確認します。

ユーザーストーリーのリファインメントを行う目的は、チームで意図と範囲が完全に理解されていることを確認することです。 ストーリーのリファインメントとは、ストーリーの内容を改善して、準備度の定義を満たす反復的なプロセスです。 The Pega Express^™のデリバリーアプローチでは、あらゆるステークホルダーと確実に協力できるようにするために、目的の直接把握（DCO）を促進しています。 リファインメントプロセス全体でDCOが活用され、各ユーザーストーリーにあらゆる観点から情報が含まれていることを確認します。 

ユーザーストーリーのリファインメントは、簡単な説明のような下書きのストーリーから始まります。 サイジングする技術チームに引き継ぐと、ユーザーストーリーのリファインメントは終了します。 

ユーザーストーリーの下書き

ビジネスアーキテクト、プロダクトオーナー、その他の関連するステークホルダーは、ビジネスの目的とユーザー要件が明確になるようにユーザーストーリーについて話し合います。 それが終わった後に、ステークホルダーはユーザーストーリーを技術チームと共有し、さらにリファインメントを行います。

リファインメント

ビジネスチームとテクニカルチームが協力して行います。 このコラボレーションにはプロダクトオーナー、対象分野のエキスパート（SME）、UXデザインのスペシャリスト、テストスペシャリスト、ビジネスアーキテクト、システムアーキテクト、ITスペシャリストが加わります。 チームはユーザーストーリーを確認して、詳細を明らかにします。 ユーザーストーリーのリファインメントでは、ユーザーストーリーを詳細に話し合い、適切に文書化されているとチームが納得するまで、いくつかのDCOセッションが必要になる場合があります。 

ユーザーストーリーの性質によっては、次のようなアーティファクトを追加する必要があるかもしれません。 

• ユーザーストーリーの承認メール
• UIワイヤーフレーム
• プロセスマップ、ビジネスルール
• 決定ロジックダイアグラム

リファインメントセッションの一環として、技術チームは合格基準について解釈し、その成果をアプリケーションで設定する必要のあるコンポーネントに変換します。 技術チームは、ストーリーの他のユーザーストーリーとの依存関係や、既存の機能や特定の複雑な分野に与えるかもしれない影響も見極めます。

技術チームは、特定のユーザーアクセシビリティ要件などの機能以外の要件を考慮する必要があるかもしれません。 これらの要件は、ユーザーストーリーで文書化されていないと、失われてしまうかもしれません。 リファインメントを行う際、チームは追加の添付ファイルまたは特定の合格基準を通じて、ユーザーストーリーにそれらの詳細を文書化します。 

ユーザーストーリーのリファインメントを行うと、大き過ぎたり複雑過ぎたりすることに気付くかもしれません。 その場合は、複数のユーザーストーリーに分割してください。  または、リファインメント中の作業によって要件のギャップが明らかになり、バックログにユーザーストーリーを追加する必要が生じる可能性があります。

ストーリーのリファインメントが行われたら

リファインメントプロセスは、次の場合に終了します。

• チーム全員がユーザーストーリーを理解した
• すべての補足情報がユーザーストーリーに追加された
• プロダクトオーナーが合格基準を承認した  

リファインメントの後、技術チームはユーザーストーリーの規模（サイズ）を決定します。 ストーリーのサイジングにより、リファインメントが終了します。

リファインメントプロセスの一環として、技術チームはユーザーストーリーの合格基準を満たすための技術的な作業を特定します。 一部の技術的設定では、特別な注意が必要です。 チームはこれらの作業を設定作業と分離することができます。 スクラムでの作業の割り当てを促進し、再利用可能コンポーネントが適切な合格基準で開発されるようにするために、スクラムチームは技術要素のみを含むテクニカルストーリーの作成を決定する場合があります。  

一般的なテクニカルストーリーには以下のものが含まれます。

• インターフェイスコネクターの設定
• テストハーネス
• DevOpsリポジトリ
• 新しい環境
• 複数のユーザーストーリーへの対応に必要なその他の技術的要素

リファインメントを行う際、テクニカルストーリーは、これらの汎用テクニカルコンポーネントを必要とするすべてのユーザーストーリーの依存関係としてリストアップされます。 テクニカルストーリーでは、チームメンバーが並行して作業を行い、関連するユーザーストーリーを同じスプリントに導入できます。 また、チームはテクニカルアセットの開発関連作業とビジネスソリューションの開発関連作業を切り分けます。

テクニカルストーリーには、次の条件でユーザーストーリーと同じルールが適用されます。

• スプリントに割り当て準備ができているという定義を満たしている
• テクニカルストーリーではないユーザーストーリーと同じようにサイジングが行われている

ストーリーのサイズはいくつかの方法で反映できます。 ストーリーポインティング（各ストーリーにポイントを付与すること）は、リファインメントの話し合いの最後に実施されるアクティビティです。 このアクティビティの目的は、ストーリーの複雑性のサイジングを実施することです。 数字が大きいほど、ストーリーの複雑性が増大し、ストーリーの構成、テスト、実装にかかる労力も大きくなります。 一般的なアプローチでは、フィボナッチ数列を使用します。 この数列によって、チームは相対的複雑性の観点からストーリーのランキングを作成できます。

以下のフィボナッチスケールでストーリーポイントを決定します。

• 1点=非常に小さなストーリー
• 2点=小
• 3点=中
• 5点=中から大
• 8点=大
• 13点=非常に大きい
• 21点以上=ストーリーはエピックと見なされるため、小さく分割する必要があります。

複雑性バケットによる推定

ストーリーの複雑性を一貫して見積もることは、各チームメンバーの複雑性に対する見方が異なるため、難しいかもしれません。 複雑性バケットを使用してストーリーの複雑性バケットを見積もり、最終的なポイントを選択する前に、事前定義バケットの複雑性バケットについてストーリーごとに話し合うことで、チームで一貫性のあるストーリーのサイジングを行うことができます。   

準備フェーズでは、チームはストーリーの複雑性を見積もるために最も適切な基準に同意する必要があります。 各基準は複雑性バケットになります。 各バケットについて、チームは軽度から中度、高度または複雑までの複雑性バケットのランキングについて合意しておく必要があります。 たとえば、開発者はサイジングの数を決定する際に、ユーザーストーリーのUIへの影響、テストの量、構成、ビジネスルールの数、およびデータ統合について考慮します。 複雑性のレベルごとに、ポイント値を割り当てます。

一般的な複雑性バケットには、以下の要素が含まれます。

• ユーザーインターフェイス
• ビジネスロジック 
• データ
• 統合面
• テスト   

サイジングセッションでは、チームはすべての基準に照らして各ストーリーを確認し、各カテゴリーの複雑性の評価に基づいてストーリーの合計ポイントを計算します。 次に、合計を適切なフィボナッチ数とマッピングします。 フィボナッチ数列の間で完全に一致する数字がない場合、チームは合計の両端のフィボナッチ数のどちらが複雑性を最もよく表しているかについて話し合い、その値をストーリーに割り当てます。

ユーザーストーリーの見積もりが完了すると、次のスプリント計画セッションでプロジェクトオーナーが検討できます。 

アジャイルプロジェクトについて最もよく尋ねられる質問の1つは、「良いユーザーストーリーとはどのようなものですか」というものです。 ユーザーストーリーのモデルは1つではなく、チームごとに異なります。 幅広い経験と業界の背景が、ユーザーストーリーの集合的な要件に影響を及ぼします。   

次の例は、完全な詳細が説明され、技術チームでリファインメントが行われ、完了の定義に照らしてレビューされ、開発の準備ができていると宣言された良いストーリーとはどのようなものかを示しています。 この例では、次の要素を探します。

• ストーリー名
• 説明 
• 合格基準
• ストーリーサイズ  
• ストーリーステータス
• 追加情報 

次の問題に答えて、理解度をチェックしましょう。