アジャイルユーザーストーリーの受容基準

ユーザーストーリーが正しく完了し、顧客の要件を満たすことをどう確保できるでしょうか？ここが受容基準関与するところです。受容基準は、すべてのユーザーストーリーが完了し、すべてのシナリオが検討されることを保証する形式化された要件のリストです。要するに、ユーザーストーリーが完了とみなされる条件を定義します。明確で書かれた基準は、開発チームが顧客のニーズについて曖昧さを生じさせず、誤解を防ぐのに役立ちます。

したがって、ユーザーストーリーを書く際には、受容基準は不可欠です。それらはチームが機能開発中に必須となること、そして何に注力すべきかを理解するのに役立ちます。

受容基準について詳しく見てみましょう。

受容基準とは何か？

受容基準により、ユーザーストーリーがいつ完了したとみなされるか、そしてユーザーのニーズを満たすために必要なすべての機能が備わっているかを定義できます。

受容基準は、ユーザーストーリーが完了とみなされるために満たすべき条件のセットです。それらはユーザーストーリーの詳細な範囲と必要な内容を示すため、チームは問題の本質を理解できます。これにより、新しい機能をリリースするたびに、ユーザーが期待する水準を満たしていることを確認できます。

しかし、ユーザーストーリーが満たすべき機能的基準のリストを熱心に並べる前に、他の変数が機能の品質にどのように影響するかを検討し、それらを受容基準に含めるようにしましょう。

受容基準には以下の詳細を含めることができます

  • ユーザー体験
  • 現在のユーザーストーリーが既存の機能に与える影響
  • 速度などの重要なパフォーマンス
  • ユーザーストーリーが意図する動作

したがって、構築している機能とその複雑さに応じて、チームと座って、それが実行すべき最小限の機能のサブセットとその振る舞いを決定しましょう。

もしそれが複雑であるか、製品のコア機能である場合、チームが混乱しないように、可能な限り多くの詳細な受容基準を記述することを検討すべきです。

ユーザーストーリーの受容基準の書き方

1. 受容基準はユーザーの視点から書くべきである

受容基準は顧客の視点から問題を捉える方法です。実際のユーザー体験の文脈の中で書かれるべきです。結局のところ、あなたはユーザーのために製品を構築しているのですよね？

2. 基準は明確で簡潔であるべき

受容基準はテストケースやドキュメントと混同してはいけません。基準をできるだけシンプルで明確に保つことが重要です。

3. すべての人が受容基準を理解しなければならない

開発者が理解できない場合、あなたの基準は無意味です。明確さに不安がある場合は、質問をし、すべてが明確になるまで調整する時間を確保しましょう。

4. 受容基準は『どのように』（How?）についてではなく、『何を』（Why?）についてです

ユーザーストーリーと同様、受容基準はタスクではありません。ユーザーストーリーを伝える手段です。

5. 受容基準は具体的であるが、別の詳細レベルではない

税務申告ソフトウェアを例に挙げましょう。最も重要な要件は、収入と支出に基づいて正しい税額を計算することです。明確ですよね？そして、すべての可能な組み合わせをテストすることはできないことをご存知でしょう—可能性はほぼ無限に近いからです。

したがって、ユーザーストーリーの受容基準は、満たされなければならない具体的な条件や要件を指定します。これは、より具体的になることを意味し、別の詳細層を追加するものではありません。これにより、チームは必要な内容を理解しやすくなり、納品が早まります。もちろん、現在のバーンダウンチャートを過去のものと比較すると、いくつかの改善が見られるかもしれません。

6. 受容基準は、ユーザーの立場からユーザーストーリーを再表現したものであることができる

これはユーザーの物語が極端に複雑でない場合にのみ適用されます。私が何を意味しているのか、例を示します。

「財務担当者として、すべての財務報告を管理できるように、請求書を受け入れたい”

その受入基準は「受け入れ操作を実行すると、請求書は受け入れられます（請求書レコードを確認して検証）”

前提／条件／結果による受入基準テンプレート

生活を簡単にするために、受入基準を書く際に使える簡単なテンプレートを紹介します：

前提条件[文脈]、条件[特定の操作が実行されたとき]、結果[一連の結果が発生するべき]

受入基準の例

例としてのユーザー物語：

“執筆者として、他の人がコメントを追加したときに通知を受け取りたい。これにより、最新の状況を把握できるようにする。”

上記のユーザー物語に対する受入基準の例を3つ示します：

  1. 前提条件私の携帯電話がロックされている条件アプリが開いていないとき、結果通知バナーを受け取るべきである。
  2. 前提条件私は文書を作成している条件アプリが開いているとき、結果ベルアイコンは未読通知の件数を表示するように更新されるべきである。

例 – ウェブサイトフィードバック送信

ブログコメント機能のユーザー物語と受入基準を指定します。ログインしているユーザーはコメントを追加できます。「コメントを追加」機能のユーザー物語は次の通りです：

としてログイン済みユーザーとして、
私は次のようにしたいブログ投稿にコメントを残せるようにしたい。
その理由は話題についてフィードバックを受けられるからである。

この機能の受入基準は以下の通りである：

シナリオ：ログイン済みユーザーがブログ投稿にコメントを残す
ログイン済みユーザーであると仮定して、
特定のブログ投稿を含むページを開くと、
システムは、他のユーザーが追加したコメントのリストを表示する「コメント」セクションをブログ投稿の下に表示する。
システムは「コメントを追加」フィールドを「コメント」セクションの上部に表示する。
私が「コメントを追加」フィールドに自分のコメントを入力し、「送信」ボタンをクリックすると、
システムは私のコメントを保存する。
システムは私のコメントを「コメント」セクションの最上部に表示する。
システムは私のユーザー名とアバターを私のコメントの左側に表示する。
システムは私のコメントの反対側に「削除」および「編集」アイコンを表示する。

 

ご覧の通り、受入基準を書くことは、顧客と開発チームの両方にとってWin-Winです。チームが何をすべきかを明確に理解するだけでなく、顧客が開発プロセスを理解し、提供されたソフトウェアが実際のビジネスニーズを満たしているかを検証できるからです。

 

コメントを残す