いつものように：それは異なります。
私は現在、スプリントが2週間から4週間の間で変化する組織にいます。速度を測定することが難しくなり、組織の他のメンバーが開発チームとスケジュールを一致させるのも難しいため、私は個人的にこれに熱心ではありません。
一方、それは次のスプリントに持ち越されるストーリーが非常に少ないことを意味し、通常はスプリントが完全にキャンセルされることにつながる不在や予期しないバグなどをより簡単に考慮することができます。
私は1週間のスプリントを試したチームと関わってきました。実際には、スプリント計画、テスト計画、展開などに関連するオーバーヘッドの量は、実際の開発時間の約2日を意味し、結果として大規模な戦略的作業を行うことは困難でした。チームは現在、かんばんを使用しており、スプリント期間は固定されていません。その結果、チームははるかに幸せになっていると思います。
プロジェクトごとのスプリントの長さを決定します。3〜4週間続く小さなプロジェクトを実行している場合、1週間のスプリントを実行しても意味がなく、ほぼかんばんのようなアプローチに切り替えます。
1週間から2週間の長期プロジェクトを実行している場合。しかし、私たちが行っていないことは、スプリントの長さで絶対的に柔軟であり、最終的には私たちとの混乱を報告することを生み出しました。しかし、私たちが採用しているのは、スプリントの長さを2倍にすることです。ルーズエンドを仕上げるためではなく、なぜ私たちがものを再配置するのかを説明することなく、両方のスプリントのロードを完了することを目標としています。私たちは、可能な限りそれを避けようとしています。