ユーザーストーリーの承認基準に関する詳細はどこに記述しますか？

受け入れ基準に関するこのブログの投稿で、著者は適切な受け入れ基準は次のようでなければならないことを説明しています。

• 解決策ではなく意図を述べる（たとえば、「ユーザーはドロップダウンからアカウントを選択できる」ではなく「ユーザーはアカウントを選択できる」）

• 実装に依存しない（理想的には、この機能/ストーリーがWeb、モバイル、音声起動システムなどに実装されるかどうかにかかわらず、フレージングは​​同じです）

• 比較的高いレベルである（すべての詳細が書面である必要はない）

次のような詳細：

• 列見出しは「バランス」です
• ローリングバランスの形式は99,999,999,999.9 D / CRです。
• チェックボックスではなくドロップダウンを使用する必要があります

チームの内部ドキュメントまたは自動受け入れテストのいずれかに移動する必要があります

ただし、GUIテストを実行するためにCucumberまたは同様のフレームワークを使用することについて眉をひそめる人々をよく耳にします。さらに、内部ドキュメントを使用すると、ドキュメントを定期的に更新できないために多くの問題が発生する可能性があります。

私はまだ、お客様との会話中にそのような詳細をキャプチャする効果的な方法を見つけるのに苦労しています。

私には2つの場所があります（製品の所有者として）

顧客からの新しいフィードバックは、より多くのストーリー、ストーリーの優先順位の変更、またはストーリーに関するいくつかの新しい詳細に翻訳できます。バックログでは、そうでなければ忘れてしまうかもしれない将来の話のために、これらの詳細をメモします。これらは私自身のためのメモです。

計画会議の直前に、頭の中にあるものとこれらのメモをチームがレビューできるものに翻訳します。このドキュメント（ユーザーの叙事詩ごとにWikiページを使用します）は、スプリントの計画中に、チームとストーリーを話し合う一環としてさらに洗練され、完成します。

ストーリーの最後に「制約」を「PS」としてキャプチャするのが好きです。

[user] [actions] so that [goal]

Constraints:
- No Touching
- Actions must be gluten free

これらの制約は、クライアントが私の設計に課した制限であり、さまざまなソリューションを比較検討するときに考慮する必要があります。私はそれらについて事前に知る必要があるため、クライアントに多くの優先順位を与えます。

高レベルのドキュメント（機能-ストーリー-テスト）の一部として、各ストーリーBDDスタイルの受け入れテストを定義するのが好きです

WHEN [preconditions]
GIVEN [trigger action/condition/event/situation]
THEN [expected outcome]

上記のような特定の詳細は、クライアントがサインオフする画面モックアップの一部です。このような詳細は常に事前にわかっているわけではありませんが、いずれにしても「設計上の制約」に該当します。モックアップが事前にわかっている場合は、クライアントが作業を開始する前にモックアップを承認する必要があるため、モックアップと合意済みの設計制約を高レベルのドキュメントに含めます。

したがって、概念的には分離していますが、同じドキュメントに含めても害はありません。クライアントのサインオフに必要ない場合でも、機能/ストーリーのすべての要件を1か所にまとめておくと便利です。

私はどちらかというと実用的なアプローチをとっています。技術的な詳細がストーリーの受け入れに重要である場合、ブログの投稿内容に関係なく、受け入れ基準に含める必要があります。列名が「バランス」であることが非常に重要である場合、それは許容基準の一部でなければなりません。

これにより、受け入れ基準が非常に長くなる場合があります。そのような場合、「テストスイートXに合格する必要がある」という1つの許容基準があることがわかります。これは「テストスイートX」にあり、製品に関する重要な詳細をすべて記述します。