ユーザーストーリーの承認基準に関する詳細はどこに記述しますか？
受け入れ基準 についてのこのブログ投稿では、著者は適切な受け入れ基準は次のようにすべきであると説明しています。
解決策ではなく意図を述べる（たとえば、「ユーザーはドロップダウンからアカウントを選択できる」ではなく「ユーザーはアカウントを選択できる」）
実装に依存しない（理想的には、この機能/ストーリーがWeb、モバイル、音声起動システムなどに実装されるかどうかにかかわらず、フレージングは同じです）
比較的高いレベルである（すべての詳細が書面である必要があるわけではない）
次のような詳細：
- 列見出しは「バランス」です
- ローリングバランスの形式は99,999,999,999.9 D/CRです。
- チェックボックスではなくドロップダウンを使用する必要があります
チームの内部ドキュメントまたは自動受け入れテストのいずれかに移動する必要があります
ただし、GUIテストを実行するためにCucumberまたは類似のフレームワークを使用することに顔をしかめる人がよくいます。さらに、内部のドキュメントを使用すると、ドキュメントを定期的に更新できないために多くの問題が発生する可能性があります。
お客様との会話中に、そのような詳細をキャプチャする効果的な方法を見つけるのに苦労しています。
「制約」を「PS」としてキャプチャしたい私の物語の終わりに。
[user] [actions] so that [goal]
Constraints:
- No Touching
- Actions must be gluten free
これらの制約は、クライアントが私の設計に課した制限であり、さまざまなソリューションを比較検討する際に考慮する必要があります。私はそれらについて事前に知る必要があるため、クライアントに多くの優先順位を与えます。
私には2つの場所があります（製品の所有者として）
顧客からの新しいフィードバックは、より多くのストーリー、ストーリーの優先順位の変更、またはストーリーに関するいくつかの新しい詳細に翻訳できます。バックログでは、そうでなければ忘れてしまうかもしれない将来の物語のために、これらの詳細をメモします。これらは私自身のためのメモです。
計画会議の直前に、頭の中にあるものとこれらのメモをチームがレビューできるものに翻訳します。このドキュメント（ユーザーの叙事詩ごとにWikiページを使用します）は、チームとストーリーを話し合う一環として、スプリントの計画中にさらに洗練され完成します。
私はどちらかというと実用的なアプローチを採用しています。技術的な詳細がストーリーの受け入れにとって重要である場合、ブログの投稿内容に関係なく、受け入れ基準に含める必要があります。列名が「バランス」であることが本当に重要である場合、それは許容基準の一部でなければなりません。
これにより、受け入れ基準が非常に長くなる場合があります。そのような場合、「テストスイートXに合格する必要がある」という1つの許容基準があることがわかります。それは「テストスイートX」にあり、製品に関する重要な詳細をすべて記述します。
高レベルのドキュメント（機能-ストーリー-テスト）の一部として、各ストーリーBDDスタイルの受け入れテストを定義するのが好きです
WHEN [preconditions]
GIVEN [trigger action/condition/event/situation]
THEN [expected outcome]
上記のような特定の詳細は、クライアントがサインオフする画面モックアップの一部です。このような詳細は常に事前にわかっているわけではありませんが、いずれにしても「設計上の制約」に該当します。モックアップが事前にわかっている場合は、クライアントが作業を開始する前にモックアップにサインオフする必要があるため、モックアップと合意済みの設計制約を高レベルのドキュメントに含めます。
したがって、概念的には分離していますが、同じドキュメントに含めても害はありません。クライアントのサインオフに必要ない場合でも、機能/ストーリーのすべての要件を1か所にまとめておくと便利です。