スプリントの目標が達成されない場合はどうなりますか？
私はスクラムガイドを読んでいますが、一部が欠けています。 スプリントの目標がまったく満たされない場合はどうなりますか？スプリントの目標は機能の大部分であり、それ以上分割できないため、開発者は2週間（スプリントの期間）をそれを達成するかどうかはわかりませんが、彼らはそれを実行できません。この機能はどうなりますか？
- それは捨てられるべきですか？ （ありそうもない）
- 次のスプリントでも継続する必要がありますか？はいの場合、各スプリントでリリース可能な製品の増分を作成するルールと、スプリントの期間が固定されているというルールに違反しませんか（技術的にはルールは有効ですが、実際には4週間のスプリントがあります）。
スプリントの目標はバックログに戻し、バックログ内の他のすべてのストーリーと一緒に再評価する必要があります。ほとんどの場合、これは、バックログの最上位に優先され、次のスプリントに引き込まれることを意味します。理論的には、バックログが最後に優先されてからビジネスニーズが変化した場合、それは後のスプリントのために残されたり、破棄されたりする可能性があります。しかし、重要な概念は、バックログの他のストーリーと同じように扱われるということです。
これが頻繁に発生する場合は、ストーリーをどのように書いているかを再評価する必要があります。これは、1回のスプリントで終了するのに十分な粒度のストーリーを作成していない可能性があるためです。しかし、開発の気まぐれは、それが最高のチームでさえ時々起こることを意味します。
（この時点で、ストーリーを2つに分割して、この状況に対応するチームもあります。1つ目は完了した作業で、2つ目は必要な新しい作業です。これは、後で人為的に見栄えが良くなると思うので嫌いです。 -事実。）
「スプリントゴール」と言っているように聞こえますが、「製品が実行する必要があることの非常に大きな部分であり、現在は実行していない」という意味です。これは、エピック、テーマ、ストーリーマップなどを含むより良い製品バックログを作成する方法についての個別の議論になる可能性があります。
今のところ、改善に焦点を当てるものは次のとおりです：
- スプリントの目標をよりよく理解する
- 作業をより管理しやすいサイズに分解するための障害を取り除くために時間を費やしてください
- 単一のスプリントで達成できる作業に基づいてスプリントの目標を作成する
私は＃1であなたを助けることができます：D
まず、スプリントの目標は製品バックログに存在しません。スクラムガイドによると、スプリントの目標は
...製品バックログの実装を通じて達成できるスプリントの目標セット。
スプリントの目標は、開発チームが次のスプリントで実行できる作業を予測した後、スクラムチーム全体（プロダクトオーナー、開発チーム、スクラムマスターを参照）によって作成されます。その場合、スプリントの目標は次のように理解できます。
...製品バックログの実装を通じてスプリント内で達成される目標であり、インクリメントを構築する理由について開発チームにガイダンスを提供します。
スクラムチームが製品バックログからの予測作業を処理し、スプリント目標を形成し、予期しない作業に対応し、それでもスプリント目標を達成する方法を視覚的に表したものは次のとおりです。
プロダクトオーナーが、開発チームがスプリントでの完了を予測できるプロダクトバックログで作業を定義できない場合は、次のことを言わないでください。
- スプリントを長くする
- 「スクラムはここでは機能しません」と言います
- 開発チームが完了できないスプリントに作業を取ります
皮肉なことに、スプリント（製品所有者の決定）を短縮すると、スクラムチームは、価値のある実用的なソフトウェアの小さなチャンクを作成する革新的な方法を見つける必要があります。
代わりに、「何を変更する必要があるか」と尋ねます。これは建設的に可能性の芸術に向けた議論を導き、それが今度は私たちに変化のために働くように促します。
開発者がスプリントに取り組むだけです。チームはそれが達成できると考えています。そうでなければ、死の行進を招きます（震え）。
30日以内に動作するソフトウェアを作成することは、スクラムが教える敏捷性の最も重要な側面の1つです。これらの改善をチームと組織の健全性の最優先事項にすることを検討してください。
これについては、スプリント回顧展で議論し、事後分析する必要があると思います。スプリントの目標に関する結論は明らかに異なりますが、最終的にそれを放棄するか、次のスプリントに引き継ぐかの決定は、プロダクトオーナーに帰属する必要があります。