スクラム：ショートVSロングスプリント
私たちは、プロジェクトに最適なスプリントの長さを見つけようとしていました。 3週間ベースで作業した後、スプリントを2週間に削減すると、速度が向上すると考えました。
利点は明らかでした-短いフィードバックループ、小さなストーリー（ユーザー価値あり）など。一方で、セレモニー（企画、回顧）など、多くの短所があり、私たちが制作しておらず、今より頻繁に発生しています。
新しいチームのために、スプリントの最適な長さをどのように決めることができるのでしょうか。
少し後ろ向きに見ていると思います。速度は、チームが行っている作業の後処理です。それはではありません原因因子です-つまり。それはあなたが測定するものであり、直接調整できるものではありません。
この 速度の説明 には、質問に関連する情報があります。
速度を定義する最も簡単な方法は、チーム/プロジェクトが1つのスプリントで実行できる数またはユーザーストーリーです。
そしてその定義によれば、スプリントが長いほど、スプリントごとの開発時間が長くなり、速度の数値が大きくなります。
2週間または3週間のスプリント間の相対速度は、少し異なる質問です。プロジェクトセレモニーのオーバーヘッドは、利用できる全体的な時間が少ないため、どれだけの作業を完了できるかに影響を与える可能性があります。この計算は、スプリントで利用可能な開発時間を特定する方法として検討してください。
DevHoursAvailable = ((HoursInDay * DaysInSprint) - CeremonyOverhead) * AvailabilityFactor * NumberOfDevs
CeremonyOverheadは一般的に修正されています。 DaysInSprintを減らすと、そのスプリント中に開発に利用できる時間が少なくなることがわかります。 1 devの単純な例を使用して、いくつかのスプリント長の数値を次に示します。
1週間：
（（8 * 5）-4）* .8 = 1日あたり28.8時間または5.76時間。
2週間：
（（8 * 10）-4）* .8 = 60.8時間または1日あたり6.08時間。
3週間：
（（8 * 15）-4）* .8 = 92.8時間または1日あたり6.18時間。
「明白な」答えは、より長いスプリントの方が良いということです。明白な答えの問題は、フィードバックループの有益な影響を無視することです。アジャイルが開発プロセスにもたらすと思われるものについての全体的な視点で、その計算に関する考えを和らげます。
あなたの中心的な問題は、ユーザーストーリーが定義されているほど明確ではないことだと思います。何が必要かを理解していないことが、仕事を成し遂げるための本当の障害です。
一方で、セレモニー（企画、回顧）などのデメリットも多い
これは大きな赤旗です。作業プロセスとその改善に役立つ重要な手段ではなく、儀式としてそれを見る場合、おそらくそれに取り組むことは、スプリントの長さをいじるよりも多くの利益をもたらします。
プロセスは（チームを意味する）あなたの手に委ねられています。実験と調整が必要な場合は、見栄えの良いアイデアを追いかけることになっています。私たちは2週間行っていましたが、最終的には3週間に切り替わりました。ただし、スコープの見積もりに基づいて長さを設定することもあります。ええ、私は「等しい長さ」の考えを知っていますが、それは教義ではなく、実際のプロジェクトに実際には適合しないかもしれません。また、明確で明白なスプリントの目標を設定することは、より効果的です。
適切な長さは、実際には外部から推定できるものではありません。あなたは関連する要因を知るためにそこにいます。計画では、「OK、次のX週間で何ができるか」から始めることができます。または、代わりに「次の賢明な増分は何になるか」。いずれにせよ、後者を計画することは良いことであり、それからそれがどのくらいの時間を要するかを見てください。そして、1つまたは複数のスプリントの部分。
あなた次第。両方を試して、何が機能するかを確認してください。それを使用してください。
私が今まで使った中で最高のアジャイル「スプリント」は6週間でした。私たちは多くのことを成し遂げました-しかし、私たちはそのスケジュールでクライアントに配達する必要がありました。私たちはタスクを使用せず、ユーザーストーリースタイルの作業よりも作業を優先しました。
それは、あなたが「新しいチーム」をどのように説明するかによります。
実際、チームのベロシティは、多くのパラメータ（ジュニア、シニア、ニューカマー、チームメンバー間の緊張など）の多くに依存します。
したがって、「理想的な」スプリント長もこれらのパラメーターにバインドされます。
とにかく、そのための特別なソリューションはありません。唯一の方法は、チーム自体でそれをテストし、すべてのチームメンバーの平均の最適性を考慮することです。
newチームについて質問されたので、いくつか考えを追加したいと思います。私は15年以上スクラムおよび他のアジャイルメソッドを使用しており、現在常に新しいチームは1週間のスプリントから始めることをお勧めしています。これには3つの重要な理由があります。
- スプリントが短いほど、チームはより高速なパフォーマンス状態に到達できます。ロングスプリントは通常、その状態になるまでに18か月から2年かかることを意味します。 1週間という短いスプリントは、チームが2〜3か月でその高性能な状態に到達するのに役立ちます。もちろん、高いパフォーマンスを得るには他にも必要なものがあります（カッツェンバッハとスミスによる「チームの知恵」を参照）。
- 他の人が述べたように、短いスプリントはフィードバックサイクルを増やします。 1週間のスプリントは、ソフトウェア開発や製品開発を行うほとんどのチームに最適です。フィードバックは主に、従来のUATプロセスの代わりとなるスプリントレビュー中に行う必要があります。
- 最後に、短めのスプリントは、頻繁な納品に対する組織の障害に対処するようチームに圧力をかけます。この圧力は最初は非常に不快ですが、計画、コンプライアンス、リリースなどを含む開発プロセス全体を改善するために不可欠です。
スプリントの長さを選択するための21のヒント と呼ばれる記事を書きました。
私はあなたの「より短いフィードバックループ」の提案に質問します。チームはお客様と毎日協力する必要があります。フィードバックはスプリントレビューとレトロスペクティブを待つべきではありません。テスト、コード作成、設計、フィードバックの取得即時。
個人的には、3週間のスプリントが好きです。というのも、真ん中の1週間はチームに「フロー」時間を与えることができるからです。つまり、最初の週を盛り上げる時間（これらの新しいストーリーが何を意味するのかを学ぶ）と、最後の週を締めくくる（レビューの準備をする）時間が常にあります。作業用ソフトウェアを単純に作成する中間週は、本当にすばらしいことです。
このロジックをさらに進めると、4週間のスプリントはさらに意味があります。ただし、スプリントの延長を開始すると、緊迫感が失われる可能性があります。さらに、人やチームが一度に意識的に把握して保持できる比較的小さな情報の塊があります-スプリントが長いほど、より多くのことに集中しようとするため、物事をより困難にすることができますより簡単に。また、物事を大きく広げすぎると、どの外部要因が入り込むかを判断するのが難しくなります。
セレモニーには目的があります。目的を認識すると、オーバーヘッドではなく付加価値があることがわかります。
計画-仕事に取り組むだけでなく、チームメイトと協力する方法を理解します。 スクラムチームでのコラボレーションの不足について人々が不満を言うとき、私は問題の一部として彼らのスプリント計画を見てみたいです
レビュー-私たちが何を構築していて、まだ関連性があるかなどに関する顧客からのフィードバックを収集します。品質チェックとしても機能します。
Retrospective-チームとして協力する方法を改善します。
より深い目的を尊重することに力を注ぐと、オーバーヘッドの問題は通常なくなります。質問への最初のコメントで述べたように、式典は一般的に直線的に拡大縮小します。
この件についてもっと知りたい場合は、記事があります： スプリント長の選択