3番目の答えは最良の方法です。スプリントは、定義された期間内に指定された量の作業を完了するというチームによる単なるコミットメントです。スプリントの途中で追加の作業を受け入れる場合は、スプリントの開始時にチームによってコミットされなかったものに取り組むことによって、元のコミットメントから逸脱していることになります。
これが私たちが行うことです：
- 「完了」と見なされるには、スプリント内のすべてのストーリーに欠陥がない必要があります
- 以前に完了したストーリーのスプリント中に見つかった欠陥はすべてログに記録され、バックログに入れられます。それらは他のものと同じように推定され、製品所有者によって優先順位が付けられます。プロダクトオーナーが欠陥よりも新機能を優先する場合、品質よりも機能を選択し、その逆も同様です。
- ストーリーポイントを欠陥に割り当てることはありませんが、計画の一環としてスプリントに受け入れられると、すべての欠陥を見積もります。チームは機能が壊れていることを認めるべきではありませんが、同じように、それらを修正するのにかかる時間を認識する必要があります。これにより、両方が達成されます。
他のソリューションの問題は次のとおりです。
「アプリで修正されたバグの90％」というストーリーがあり、そのスプリントで発生するバグの数と修正できるバグの数を推測し、予想されるワークロードに基づいて指摘します。
繰り返しますが、上記を参照してください。スプリント中に埋めることができる空のバケツの作業を避けたいと考えています。これは、チームによる定義されたコミットメントの目的を無効にします。チームは、自分たちが知らない、または見積もっていないことにどのように取り組むことができますか？
さらに、これは、実際に欠陥を装っている便利な機能でそのバケットを埋めることによって「欠陥によって設計」する製品所有者に簡単に制御不能になる可能性があります。
たとえば、スプリントの最後に常に受け入れられるサイズのストーリーを用意して、できるだけ多くのバグを修正します。これには明らかに、誰もが実際に8分の仕事をしているという大きな信頼が必要です。
これは奇妙に聞こえます。チームは、前のスプリントの終了時ではなく、新しいスプリント計画の開始時に作業を受け入れる必要があります。さらに、これは実際に長期的にあなたの速度を歪めます。スクラムはストーリーだけでなく製品バックログアイテムを指すため、PBIとして欠陥を含めることができないと言うことは何もありません。
バグを記録しますが、次のスプリントまでバグに取り組みません。それらは、個別にまたはグループとして指すことができます。これには、より「汚い」という利点がありますが、基本的に1時間の修正で3週間の遅延が発生します。
あなたは興味深い点を指摘し、私たちはこれについても懸念を抱いていました。ただし、その1時間の修正は（それがどれほど速いかに関係なく）、バックログの他のものと積み重ねられたときに十分に費やされた時間ではない可能性があります。肝心なのは、これらの決定を製品所有者に押し付け、チームが努力するすべてのものに優先順位を付ける自由を彼らに与えたいということです。