イテレーション計画はイテレーション自体の一部ですか？
開発を3つのフェーズ（計画会議など）、機能の進捗状況（ソフトウェア開発/ユーザーストーリーの実装）、およびファイナライズ（レビュー会議など）のタイムボックスに分割した場合。反復/スプリントとは何ですか？イテレーションには計画とファイナライズも含まれていますか、それともイテレーション/スプリントの「外側」の進捗のこれらの部分ですか？バーンダウンチャートを作成し、計画段階（ユーザーストーリーと見積もりの追加）の間に開始したい場合、バーンダウンはやや役に立たない...理想的なラインに到達することは決してないため（数日遅れて開始するため）バックロググルーミングおよび計画会議後のキックオフ。
その問題をどのように解決しますか？
反復をすぐに続くタイムボックスとして計画しますか（計画とファイナライズを含む）、またはこのタイムボックスの外で計画とファイナライズを行いますか？
「イテレーションがすべて」という考え方で私が気に入らないのは、すでに開始されていることと、私がすでにいる場所を計画し、安定しているべきだと言われている場所を変更することです（イテレーションのために） 。イテレーション/スプリント中にイテレーションバックログを変更しないでください！？計画が内部にあり、ユーザーストーリーを追加してチームで見積もる必要がある場合、これをどのように行うことができますか。私の見解では、チームの反復バックログは、ユーザーストーリーの実装の機能的な進捗/作業を開始した時点からスプリント内で修正されます（他の方向に誘導されるべきではありません）（まれな例外を除いて、たとえば、やり残し）。つまり、あなたは「アジャイル」であり、最大1週間のタイムボックス内で反応することができます。 「アジャイル」とは、正当な理由がなくても、すぐにハンマーを片付けて反復目標を変更することを意味するとは思いません。
賛成/反対の議論は何ですか？
スプリントは、スプリントで行われるすべての作業のコンテナです。これには、計画、スプリントレビュー、回顧、およびその間のすべての作業が含まれます。
バーンダウンを調整して2日目に開始し、スプリントレビューの前日をターゲットにすることを妨げるものは何もありません。
Spritn Burndownは、理想的な線に沿って従うことを意図したものではありません。理想的なラインは、チームが現在の計画より進んでいるか遅れているかを評価して、行動を起こし、計画を調整できるようにするのに役立ちます。
ソフトウェア開発は複雑になる傾向があり、泥だらけになる可能性があります。正直なチームが理想的な方針に従うことはめったにありません。彼らは途中で新しい仕事を見つけ、より良いかもしれない代替案を見つけ、フィードバックを受け取り、以前は計画されていなかった新しいコーナーケースを見つけます。バーンダウンがこれらの変更を継続的に反映している場合、チームはそれを使用して情報に基づいた意思決定を行うことができます。
PS：GroomingはRefinementに名前が変更されました。この背後にある理由は、ワードグルーミングに関連する否定的な意味合いと関係があります。幼い子供や厄介な年配の男性（一般的に）とウェブカメラと関係があります。
スクラムでは、 スクラムガイド で定義されているように、スプリントには「スプリント計画、毎日のスクラム、開発作業、スプリントレビュー、およびスプリント回顧展」が含まれます。したがって、スクラムの観点からの質問に対する答えは「はい」です。イテレーションの計画（およびイテレーションのレビュー）は、イテレーション自体の一部です。
ただし、アジャイルになる方法はスクラムだけではありません。スクラムが何かがそうしないと言ったからといって。計画や遡及的活動を除いて、スプリントを時間に基づいて行うことを選択できます。
しかし、理想を決して満たさないというあなたの懸念はそれほど大きな懸念ではないと思います。理想的なラインはまさにそれです-理想的です。一定の安定した作業を前提としています。これは、反復タイムボックスに対してストーリーポイントを完了することをどのように行っているかを示す指標です。理想的な方針に正確に従うことはおそらくないでしょうが、コミットメントの達成が危険にさらされている場合は、それを使用して利害関係者に早期警告を発することができます。
「イテレーションがすべて」という考え方で私が気に入らないのは、すでに開始されていることと、私がすでにいる場所を計画し、安定しているべきだと言われている場所を変更することです（イテレーションのために） 。イテレーション/スプリント中にイテレーションバックログを変更しないでください！？計画が内部にあり、ユーザーストーリーを追加してチームで見積もる必要がある場合、これをどのように行うことができますか。私の見解では、チームの反復バックログは、ユーザーストーリーの実装の機能的な進捗/作業を開始した時点から修正されています。
従来の計画主導の手法をアジャイル手法に適用しようとしているようです。それはうまくいきません。
まず第一に、反復は安定していることが保証されていません。理想的には、それらはほとんど安定している必要があります。スクラムガイドに従って本のスクラムを実行している場合は、開発チームがスプリントバックログを変更できるという事実も認めています。
第二に、スプリント計画は詳細な計画ではありません。チームがスプリントで提供できるものと、提供するために実行する必要のある作業の2つの問題のみを扱います。プロダクトオーナーは通常、達成する目的を念頭に置いており、開発チームと協力して、その目的と技術的な考慮事項に基づいてプロダクトバックログを注文します。開発チームとプロダクトオーナーは、要件とそれらの要件を実装するために必要なタスクを定義するために継続的に協力します。
より固定された作業、より計算された応答に慣れている場合、アジャイルは困難になります。アジャイル手法は、応答性とデータ駆動型であるだけでなく、協調的であることを目的としています。しっかりとした計画や行動を前もって設定することはありません。その多くは経験から得られたものであり、誰もが正しいことだと感じています。
計画はスプリントの一部です。
プログラミングとテストのために取っておかれた時間のブロックであるかのように、スプリントを見ているようです。それはスプリントが何であるかではありません。スプリントは、人々のチームが問題に一緒に取り組むために取っておかれる時間のブロックです。その作業の一部はコーディングですが、その作業の一部は計画であり、一部はデモと回顧展であり、その一部は家に帰って眠っています。
バーンダウンに関しては...バーンダウンチャートの理想的な線は目標ではなく指標であるということを覚えておくことが重要です。スプリントの終わりにまだやるべきことがない限り、問題はありません。
唯一の目的は、時間どおりに終了する可能性が高いかどうかを確認できるようにすることです。その情報は、スプリントの最初の1日か2日はほとんど作業を行っていないため、ほとんど役に立たないため、計画がグラフにどのように影響するかはそれほど重要ではありません。スプリントの最後の数日間も（おそらく）完全に役に立たない。それまでに、あなたはあなたが終了するかどうかをすでに知っているはずだからである。
したがって、バーンダウンチャートは、実際にはスプリントの中央部分でのみ役立ちます。それが面倒な場合は、計画の後、デモと回顧展の前に開始するバーンダウンチャートを確実に描くことができますが、プロセスを必要以上に複雑にしていることになります。