ユーザーストーリーをスクラムで完了したとマークするのはいつですか？
各スプリントの終わりに実行可能なユニットの配信を強調するスクラムの概念があります。各実行可能ユニットは、ユーザーストーリーに直接または間接的にマッピングされます。新しいスプリントPOで新しいPBI（新しいユーザーストーリー）が導入されると、これは、実際のチームが常に以前のユーザーストーリーに戻って残りの作業を行うことができないことを意味します。つまり、ユーザーストーリーを実装するときは、その時点でチームが知っている限り完全に実行する必要があり、何も忘れないでください（「申し訳ありませんが、実装するのを忘れましたその入力コントロールの検証」または「クロスブラウザチェックがユーザーストーリーの一部であることを知りませんでした」）。一方、テスト、下位互換性、受け入れ基準、展開などの概念は、各ユーザーストーリーの後に登場します。
では、チームメンバーは、デモだけでなく、ユーザーストーリーが完了したことを完全に知ることができ、新しいものをいつ開始できるのでしょうか。
完了の定義を定義します。しかし、それはそれを作るためにすべてを含むべきです完全に完了しました。 「申し訳ありませんが、その入力コントロールの検証を実装するのを忘れました」というのは、ストーリーが完了していないため、進行中の列に戻す必要があるということです。スプリント後にそれを発見した場合、POが次のスプリントで対処できる（またはできない）バグです。 POは最終的に、イテレーションの最後に製品を出荷するかどうかを決定します。
あなたが言ったように、テストは特定のユーザーストーリーのコードが記述された後に行われます。ただし、テストは完了の定義の一部である必要があります。
したがって、完了は、ユーザーストーリーが完了の定義。
最初に、私がテスト、受け入れ基準、コードレビューなどのタスクを行う場所は、ユーザーストーリーの一部です。
第二に、ユーザーストーリーは、[〜＃〜]受け入れられたときに行われます[〜＃〜] POによって。チームが[〜＃〜] complete [〜＃〜]とマークするとすぐに、POはストーリーを受け入れてレビューします。 POがストーリーを受け入れない場合、チームはタスクを追加する可能性があります。
そして、はい、あなたは正しいですチームは、スプライン計画の間に合意された範囲に従ってストーリーを完了する必要があります。ただし、スコープとタイムボクシングは連携していないため、POと話し合った後、チームは常にストーリーのスコープを縮小することができます-反復内で完了することができるレベルまで。
合意された範囲が何であれ、既知の問題がある場合、ストーリーはCOMPLETEDとマークされるべきではありません。ただし、イテレーションの最後にPOがそれを受け入れることができます。残りのバグは重大または頻繁ではないかもしれません。
コードレビュー、完了の定義、およびユーザーストーリーが完了するために合格しなければならない高レベルの受け入れ基準の定義に加えて、各スプリントの最後にレビューがあり、ストーリーがより広いコミュニティに提示されます。私たちの会社（第1レベルと第2レベルのサポート、コンサルタント、営業担当者など）では、彼らは通常より深いドメイン知識を持っているためです。ストーリーがこのレビューを通過して初めて、それは完了したものとして扱われます。
- ストーリーごとの完了の定義は、ストーリーのdoingとdoneの間の固有かつ特定の差別化要因です。これは通常、ストーリーが完了したことを確認するために何をすべきかを説明する短い文章です。
- ストーリーが完了の定義に従って完了したと見なされる場合、それは完了したことを意味します。
- 以前に行われたストーリーに関連する何かが後でまだ実行されていることが判明した場合、その何かの新しいストーリーが、完了の新しい定義で作成されます。
- 新しいストーリーは他と同様にバックログに追加されるため、標準のスクラムフローが適用されます。
- 時間が経つにつれ、完了の定義が改善されるだけでなく、行間を読む能力も向上し、誤解が減ります。