ユーザーが変更を希望する場合、スプリントの最後にユーザーストーリーを処理する方法は？
スクラムを採用し、最初のスプリントを完了しました（ええ！）
スプリントレビューでは、機能Xのユーザーストーリーをデモしました。この機能Xは、初期のビジネス分析からユーザーストーリーに記述された方法と、製品のバックログのグルーミングとスプリントの計画中に作成した詳細を正確に機能しました。ただし、ユーザーが機能Xの動作を確認した後、いくつかの調整が必要でした（衝撃的ではなく、デモの目的とフィードバックループ）。
私の質問は：
（a）元のユーザーストーリーが完了したと見なして、将来のスプリントで新しい要件を処理するために新しいユーザーストーリーを作成しますか？
（b）元のユーザーストーリーは未完成であると見なし、次のスプリントでより多くのタスクに変わるより詳細な要件を含むバックログにロールインしますか？
（b）の場合、スプリント計画で、作業の90％が完了したことがわかったので、ストーリーのストーリーポイントの重みを再推定しますか？それで、元々5ポイントだった場合、今では2ポイントになる可能性がありますか？
新しい完成した作品が提示された後に新しいアイデアを思いつくことは、通常の反復型開発の一部です。最も重要なのは、スプリントを開始したときにストーリーがあなたが「知っている」ことをもたらすかどうかです。新しい洞察は新しい物語のためのものです。
ストーリーを開いたままにしたり、ストーリーを拒否したりするのは、話し合ったことを間違えたり、見逃したりした場合のためです。
だから間違いなくオプションA。
それはあなたの「完了の定義」に要約されます。あなたの話はそのリストに従って行われますか？
私の意見は、元のストーリーが完了したことを考慮して、次のスプリントのためにまったく新しいストーリーを作成することです。
しかし、もっと重要なことは、これから学び、それが再び起こらないようにする方法を見つけることです。回顧会議はそれを育てるのに良い場所かもしれません。より多くのユーザーフィードバックがそれと関係があるかもしれないに違いない:)
ところで、あなたの最初のスプリントおめでとう！
- 新機能：新しいストーリー
- 強化：新しいストーリー
- 欠陥：元のストーリーに対するバグ
重要なことは、アジャイル方法論では学習と変更が必要であるが、これを制御したいということです。新しいストーリーを作成することにより、これをバックログに入れ、優先順位を付ける必要があります。
これは、次のことができるようになるため重要です-進行状況を表示します。つまり、バーンアップ/バーンダウンに適切に反映されます-範囲と作業の割り当てを促進します
私は間違いなく新しい話をすることに投票します。完了の定義にクライアントがそれを受け入れることが含まれていない限り、受け入れ基準に関係なく、新しい要件を検討しているので、元のストーリーとは別に新しい変更を追跡して優先順位を付けたいと思います。
たとえば、終了したばかりのストーリーAを微調整して、ストーリーXを作成したい場合があります。ただし、クライアントが先に進んでストーリーBの新機能を最初に取得したい場合は、ストーリーXに取り組みたくありません。時間があれば、後で微調整に対処します。
個別の作業項目があると、この優先順位付けの分離が可能になります。
その多くは、大きな変更と調整の優先度に依存します。次のスプリントが変更されることを知っているクライアントは、機能をそのまま受け入れますか？彼らはその機能をそのまま受け入れませんか？
これらの質問への答えは、次に何をするか、AまたはBを推進します。
見積もりに関しては、元の見積もりを失うことに注意します。元の見積もりを失うと、見積もりを変更する必要があるスプリントの実際の速度を把握するのが難しくなります。
タスクをリンクできるJIRAのようなツールを使用する場合、要求された微調整を使用して新しいタスクをログに記録し、それを他のチケットにリンクして、このスプリントバックログに入れます（これの一部として作業していると仮定します）スプリント）。
それ以外の場合は、ストーリーポイントの値を組み合わせて元のチケットにメモを付けることができます。
変化に対するあなたの態度を称賛しなければなりません。それを受け入れて、それを使用してプロセスフローを作成する方法を理解できない場合は、何も見逃さないようにするために、より多くの計画を立てる方法について常にレトロになります。私はあなたがいつも何かを見逃していると思います、そしてより良いアプローチはクライアントの手に早くそして頻繁に機能を手に入れそしてあなたがあなたがすることを提案していることを正確に行うことです、反復します。