SCRUMの洗練されたユーザーストーリーの詳細レベル
私の質問の主な主題は、ユーザーストーリー、後バックログに入れられ、議論された、洗練された、次のスプリントに入れる準備ができています。すべての可能な詳細とすべての可能なシナリオをリストする必要がありますか？
私たちの10人のチームは、OTPを要求するシンプルなアプリページのすべての可能な詳細について話し合うために、精製会議のほぼ3時間を費やしました。 Confirm が押された場合、OTPが適切な場合は次のページに移動し、そうでない場合はエラーを表示します。
ユーザーストーリーの説明の中で、ユーザーがキーボードで1桁を削除した場合など、考えられるすべてのシナリオを書きました（JIRAを使用）。前のセルを書き込む前に最後の入力セルをタップした場合、ユーザーが戻ってこのページに再度移動した場合、1桁だけを書き込んだ場合に何が発生するかを確認し、確認をタップしてエラーラベルを表示してから削除します。再び数字、接続がない場合、ユーザーがアプリをバックグラウンドに置いて再開した場合にどうなるか...スプリント内の「洗練された」ストーリーは50行を超えるテキストでした。 「アトミック」機能を構成するため、複数のストーリーに分割することは重要ではありません。
これは正常ですか？チームの誰もが、あなたが持っているすべての可能な詳細を記述する必要があると言います。そうしないと、ユーザーストーリーはスプリント内で作業する準備ができているとは見なされません。
そして、ストーリーが開発された後、テスター、Devs、さらにはPOの間でこの不条理な非難ゲームが発生し、あらゆる可能性のあるすべての詳細/シナリオ/ユースケースをリストしたいと思うようになります。
テストマネージャーまたはPO：「申し訳ありませんが、この特殊な文字の検証を挿入すると失敗するため、この開発済みのストーリーを「完了」で処理したとは言えません。 "-> 作業した開発者ストーリー：「どこに書かれていますか？ストーリー内にそのようなユースケースはないので、ストーリーは受け入れられるべきです」
ウォーターフォールがスプリントで分割されているように見えます。アジャイルはより柔軟で反復的であるべきではありませんか？機能に取り組んでいるときに詳細が明らかになると私は本当に信じています。「テスト」する前にすべての詳細を知ることは不可能です。
要するに
いいえ、ユーザーストーリーは、何を実行するか、何をテストするかの詳細な仕様ではありません。
さらにいくつかの引数
ストーリーの目的
アジャイルマニフェスト の観点から、プロセスとツールよりも個人と相互作用を優先します。これを念頭に置いて、 ストーリーの3C を覚えておきましょう。特に：
したがって、ユーザーストーリーは、やり取りを容易にし、バックログでユーザーのニーズを具体化するためのツールにすぎません。 ユーザーに焦点を当てるのニーズと意図：「ユーザーとして....するために....」.
詳細度
また、包括的なドキュメントよりも実用的なソフトウェアを優先します。実装を開始する前に完全な仕様は必要ありません。
これは、会話や品質基準を忘れないように、いくつかのメモを書き留めることを妨げるものではありません。
しかし、ユーザーはこれらの詳細を気にしますか？ユーザーに尋ねると、最後のキャレットの処理方法に大きな関心が寄せられていることがわかりますが、それはなぜですか。
また、ユーザーのニーズが満たされている場合に別の動作を提供するとしたら、それは本当に重要でしょうか？
成功基準を含むあなたの全ストーリーは、興味深いものになるでしょうユーザーの観点から。
あなたがここで私たちに説明する内容は非常に詳細すぎると思います。ユーザーストーリーの目的は、詳細なテストシナリオを収集することではなく、テスターストーリーとは呼ばれません。そして、開発者がストーリーに基づいて開発できる場合、テスターは必要に応じてより詳細なテストケースを確実に準備できます。
オルタナティブ
テストシナリオをユーザーストーリーの前に置く代わりに、機能の開発と一緒にテストケースを開発できます。もはや滝はありませんが、並行した統合されたチームワークです。
アジャイルマニフェスト の後半をここで引用することは価値があると思います：
顧客とのコラボレーション契約交渉
計画に従った変更への対応
そのため、ストーリーの細部をすべて特定することに焦点を当てるのではなく（「契約交渉」）、お客様と協力して、ストーリーに取り組む際の要件を明確にします。多くの場合、機能の実装を開始するまで、詳細が何であるかがわかりません。
ストーリーの要件を合理的に実装したことを実証できる場合は、それを受け入れて次に進む必要があります。後で元のストーリーに欠けていた要件を特定した場合は、その要件の新しいストーリーを作成します（「変更に対応」）。
あなたの例では、誰かが実際に試してみる前に、すべてを正確に指定したいとします。それは可能ではありません。テーブルで物事を設計し、設計を実装して、それがうまくいくことを期待することはできません。ものを作成し、それらが機能するかどうかを確認し、機能しない場合は再設計する必要があります。
したがって、ユーザーストーリーでは、物事の修正を少なくする必要があります。画面はかなり合理的に見えますが、何が起こるかは明らかです。ユーザーが6桁を入力すると「確認」を押すことができ、コードが受け入れられるかどうかがわかります。6桁を入力しないと「確認」を押すことができません。 」それでおしまい。
QAが数字ではなく絵文字を入力するとアプリがクラッシュすることがわかった場合、それは別の話です。ユーザーが操作をキャンセルできないことがわかった場合、それは別の話です。ユーザーがOTCの再送信をリクエストできないことが判明した場合は、別の話です。ユーザーが別のストーリーであるタイプミスを修正できない場合（これらの4つのポイントの最初と最後が元のストーリーの一部として処理されることを期待していたと思いますが、「誰もアプリの必要性を教えてくれなかった」絵文字を入力するとクラッシュする」というのは、実際には言い訳になりません。