スプリント中のスプリントバックログの変更について混乱している

私は最近スクラムについて多くのことを読んでおり、スプリント中にスプリントのバックログを変更しても大丈夫かどうかについて、私にとって矛盾する情報を見つけました。スクラムのWikipediaの記事は、それがOKではない、と様々言う他の記事は、同様にこれを言います。また、私のソフトウェア開発教授は、スクラムの概要の中で同じことを教えました。

ただし、私はトレンチからスクラムとXPを読み、タスクボード上の計画外の項目のセクションについて説明します。そこで、スクラムガイドを調べて、スプリント中に「スプリント目標に影響する変更は行われていない」とスプリント目標の議論で「作業が開発チームの予想と異なることが判明した場合、その後、プロダクトオーナーと協力して、スプリント内のスプリントバックログの範囲を交渉します。」さらに、スプリントバックログの議論でも述べています。

スプリントバックログは、進行中の変更をデイリースクラムで理解できるほど十分に詳細な計画です。開発チームはスプリント全体でスプリントバックログを変更し、スプリント中にスプリントバックログが発生します。この出現は、開発チームが計画を進め、スプリント目標を達成するために必要な作業についてさらに学習するときに発生します。

新しい作業が必要になると、開発チームはそれをスプリントバックログに追加します。作業が実行または完了すると、推定残り作業が更新されます。計画の要素が不要と判断された場合、それらは削除されます。開発チームのみが、スプリント中にスプリントバックログを変更できます。スプリントバックログは、開発チームがスプリント中に達成する予定の作業の非常に目に見える、リアルタイムの画像であり、開発チームのみに属します。

したがって、この時点で私は完全に混乱しています。それについて考えると、2番目のアプローチを取る方が理にかなっています。バックログの個々の特定の項目は、私にとって最も重要なものではなく、むしろスプリントの目標であるように思われるため、スプリントの目標を変更するのではなく、バックログを変更できるのは理にかなっています。たとえば、製品の所有者とチームの両方がストーリーについて同じページにいると思っていたが、スプリントが進むにつれて誤解があることがわかった場合、そのストーリーを構成するタスクをそれに応じて変更することは理にかなっているようです。または、忘れられたストーリーまたはタスクがあり、スプリントの目標を達成するために必要な場合、スプリント中にストーリーまたはタスクをバックログに追加するのが最善だと思います。

しかし、スプリントのバックログへの変更は大丈夫ではないと断固として思われる人がたくさんいます。どういうわけかその位置を誤解していますか？それらの人々はどうにかしてスプリントのバックログを異なって定義していますか？スプリントのバックログについての私の理解は、スプリントのバックログは、ストーリーとそれらが分解されるタスクの両方で構成されるということです。

とにかく、私はこの問題に関する意見を本当に感謝します。私は、理想的なスクラムアプローチがスプリント中にスプリントバックログを変更することと、スクラムを開発にうまく使用する人々がスプリント中にスプリントバックログを変更できるかどうかの両方を把握しようとしています。

まず第一に、それについて厳しい規則はありません。スクラムのポイントは、状況に適応できるようにすることです。したがって、絶対に必要な場合（重要な何かを忘れた場合など）、スプリント中にスプリントバックログを変更できる必要があります。

しかし、スプリント中のスプリントバックログへのこの変更には抵抗する必要があります。スプリントの短い点は、プロジェクトのタイムライン全体（複数のスプリント）に影響を与えることなく、新しい作業を次のスプリントに（正しく優先順位付けした後）追加できることです。

ただし、このスプリントのタスクの1つで作業が重要な場合、2つのオプションがあります。

1. スプリントに新しいアイテムを追加します。
   ただし、同等のサイズのアイテムをスプリントから削除します。
2. このスプリントから不適切に計画されたアイテムをドロップします（次のスプリントで適切に計画できるように）。
   • 製品バックログの上部から（適切なサイズの）代替を追加します（これは、スプリント計画会議からの優先順位である必要があります）。
   • または、すべてのスプリントアイテムが完成したら、開発者が製品のバックログからスラックを取得できるようにします。

だから私はあなたがおそらくスプリントのバックログを変更するべきではないというキャンプにいます。ただし、例外的な状況が存在する可能性がある状況を考慮する必要があります。ほとんどの場合、オプション2を使用して、開発者がバックログからタスクのスラックを取得できるようにします。

次に、次の計画会議で新しいタスクが適切に分析され、スプリントに追加されます（必要に応じて）。

スプリントは短く、開発サイクルの終わりではなく、次のドロップのマークだけを覚えておいてください。製品の所有者は、次のスプリントの終了を待てない機能に非常に必死でなければなりません。

混乱は曖昧な言語によるものです。

スプリントバックログには2つの詳細レベルがあります。まず、チームが提供することを約束したアイテム（ユーザーストーリー）のリストです。第二に、チームがこれらのストーリーのそれぞれを提供するために行うのは、すべてのタスクです。

だから、人々がスプリントのバックログについて話すとき、彼らは彼らが何を意味するかを本当に明確にすべきです。スクラムガイドを読むと、スプリントバックログは、スプリント用に選択された製品バックログアイテムのセットに加えて、製品の増分を配信し、スプリント目標を実現するための計画です。

したがって、製品バックログアイテムのリストと、それらを配信する計画（タスク）の両方です。

現在、多くのチームは、提案されたすべてのタスク（計画）をスプリントの開始時に追加して、残り時間に基づいてバーンダウンチャートを追跡できるようにしています。他のチームは、必要に応じてタスクを出現させます。これは「スプリントバックログ」に追加してもかまわないときです。チームがアイテムを提供し、スプリントの目標を達成するために検査と調整を行うためにそれを行う必要があるためです。

特定の状況下では、チームはスケジュールに十分余裕があり、（チームの能力を向上させる可能性のある他のすべての有用なタスクを排除したため）プロダクトオーナーと協力して別のストーリーを選択することがあります製品バックログ...ただし、そのスプリント内で完成し、スプリントの目標と一致するという確信がある場合のみ。

だから、それがあります。はい...チームは必要に応じてタスクをスプリントバックログプランに追加します。いいえ、彼らは通常、スプリントの範囲を定義するバックログアイテムのリストに追加しません。

これで状況が明らかになることを願っています。

それはあなたの状況に依存します。計画中に一部の情報が失われ、その後、いくつかのストーリーにいくつかのポイントを変更または追加する必要があることがわかった場合、それは問題ないと思います。しかし、はい、機能の範囲が完全に変更される場合、それは極端な状況であり、異なる方法で処理する必要があります。

しかし、もちろん、計画中、誰もが自分が取り組んでいる各機能について明確に知っており、議論していると想定されています。議論と計画が適切であれば、ほとんどすべての場合、実際に修正する必要はありません。

答えに同意します。ストーリーが開発を開始した場合、それが完了するまで停止することはできません。

早くかかとを掘ります。変更を求める人は難しい方法を学ぶ必要があります。さもなければ、あなたがとにかくあなたが好きなことをすることができると知ったら、あなたは計画を立てることになります。

品質は焦点から来るものであり、バグは思考の列を落とすことから来ることを引用してください。コンテキスト切り替えのコストを引用してください。借金を追跡し、中途半端な仕事に対処するための物語の執筆と議論、参加の管理は費用がかかります。このルートから始めないでください。

アイデア：各四半期を妥協点として使用するために、管理者に3つの切り替えクレジットを与えます。