SCRUMスプリントの未完成のストーリーとタスクをどうするか？
スプリントのストーリーの一部である未完了のタスクがあります。それらはPOによって受け入れられません。それらは、次のスプリントの計画に含める必要があります。ストーリーは移動する必要がありますが、タスクについてはどうでしょうか？それらを再度開いて、ストーリー内の次のスプリントに移動しますか？
私がこれらの問題に対処するために使用したアプローチは、次のスプリント計画会議でそれらに対処することです。
すべての未完了のタスクを自動的に次の反復にロールオーバーしますか？
それぞれを確認して、次のスプリントでもそれが必要かどうかを再評価しますか？
追加された新しい項目の前、「と」（インターリーブ）、または後の未解決のタスクを確認しますか？
未解決のアイテムについて再投票しますか？前回のスプリント計画で「2」に投票されたために完了しない項目が見られたことがありますが、たとえば5に近いことが判明したため、作業量の決定を再検討する必要がある場合があります。
私の頭に浮かぶ質問は、次のとおりです。 SCRUMの純粋さだけが重要である場合は、最も便利なものを使用します。覚えておいてください：成功に焦点を当てることは、次のプロセスよりも重要です。
開始されたタスクは、可能な限り完了する必要があると思います。タスクが本当に大きい場合は、もちろん中止する必要があります。タスクを中止すると、開発者を困らせ、お金を浪費します。
開始されていないタスクについては、ストーリーとともに移動します...？ここでは問題がよくわかりません。
物理的なスクラムボードを使用していたとします。
未完了のストーリーは残り、完了したタスクは完了列にとどまるか、クリーニング（選択）でき、実行中のタスクも実行列に残るか、TODOに移動します（優先順位を変更した場合）。変更されるのは、スプリント番号がインクリメントされることだけです。
これはJiraでも同じです。未完成のストーリーとタスクをすべて新しいスプリントに切り替えます。
経験豊富なチームが、タスクを含むすべてのストーリーを次の反復に移します。ただし、このような経験豊富なチームは、時間を「コスト要因」として追跡しません。
ほとんどのチームは費やした労力を目に見えるようにしたいので、ストーリーを2つの部分に分割します。受け入れられたタスクはスプリントに留まり、完了したタスクは次のスプリントに複製されたストーリーに移動されます。
危険なのは、チームによって達成された不正確な速度に隠れていることです。分割されたストーリーは推定（ストーリーポイント）を維持しますが、チームは未完成のストーリーに対して0を達成しました！