スクラム：ショートVSロングスプリント

私たちは、プロジェクトに最適なスプリントの長さを見つけようとしていました。3週間ベースで作業した後、スプリントを2週間に削減すると、速度が向上すると考えました。

利点は明らかでした-短いフィードバックループ、小さなストーリー（ユーザー価値あり）など。一方で、セレモニー（企画、回顧）など、私たちが制作しておらず、より頻繁に発生するデメリットもたくさんあります。

新しいチームのために、最適なスプリントの長さをどのように決定できるのかと思っていました。

少し後ろ向きだと思います。速度は、チームが行っている作業の後処理です。それは原因となる要因ではありません -つまり。それはあなたが測定するものであり、直接調整できるものではありません。

この速度の説明には、あなたの質問に関連する一口があります。

速度を定義する最も簡単な方法は、チーム/プロジェクトが1つのスプリントで実行できる数またはユーザーストーリーです。

そしてその定義によれば、スプリントが長いほど、スプリントごとの開発時間が長くなり、速度の数値が大きくなります。

2週間または3週間のスプリント間の相対速度は、少し異なる質問です。プロジェクトセレモニーからのオーバーヘッドは、利用できる全体的な時間が少ないため、実行できる量に影響を与える可能性があります。この計算は、スプリントで利用可能な開発時間を特定する方法として検討してください。

DevHoursAvailable = ((HoursInDay * DaysInSprint) - CeremonyOverhead) * AvailabilityFactor * NumberOfDevs

CeremonyOverhead通常は修正されています。減らし、あなたDaysInSprintと、あなたがそのスプリント中に開発のためのより少ない利用可能な時間を持っていますどのように見ることができます。1 devの簡単な例を使用して、いくつかのスプリント長の数値を次に示します。

1週間：
（（8 * 5）-4）* .8 = 28.8時間または1日あたり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週間でした。私たちは多くのことを成し遂げました-しかし、私たちはそのスケジュールでクライアントに配達する必要があるだけでした。私たちはタスクを使用せず、ユーザーストーリースタイルの作業よりも作業を優先しました。

それは、あなたが「新しいチーム」をどのように説明するかによります。

実際、チームのベロシティは、多くのパラメータ（ジュニア、シニア、ニューカマー、チームメンバー間の緊張など）の多くに依存します。

したがって、「理想的な」スプリント長もこれらのパラメーターにバインドされます。

とにかく、そのためのすぐに使える解決策はありません。唯一の方法は、チーム自体でそれをテストし、すべてのチームメンバーの平均の最適性を考慮することです。

「より短いフィードバックループ」についてのあなたの提案に質問します。チームはお客様と毎日協力する必要があります。フィードバックはスプリントレビューとレトロスペクティブを待つべきではありません。テスト、コーディング、設計を行い、フィードバックをすぐに得る。

個人的には、3週間のスプリントが好きです。というのも、真ん中の週はチームに「フロー」の時間を与えることができるからです。つまり、最初の週を盛り上げる時間（これらの新しいストーリーが何を意味するかを学ぶ）と、最後の週を終える時間（レビューの準備）は常にあります。単純に実用的なソフトウェアを作成するための中間週は、本当に良いことです。

このロジックをさらに進めると、4週間のスプリントはさらに意味があります。ただし、スプリントの延長を開始すると、緊迫感が失われる可能性があります。さらに、人やチームが一度に意識して考え、把握できる情報の量は比較的少ないのです。スプリントが長いほど、より多くのことに集中しようとします。より簡単に。また、物事を大きく広げすぎると、どの外部要因が入り込むかを判断するのが難しくなります。

あなたは新しいチームについて尋ねたので、私はいくつかの考えを追加したいと思いました。私は15年以上スクラムおよびその他のアジャイル手法を使用しており、現在、新しいチームは1週間のスプリントから始めることを常にお勧めしています。これには3つの重大な理由があります。

• スプリントが短いほど、チームはより高速なパフォーマンス状態に到達できます。ロングスプリントは通常、その状態になるまでに18か月から2年かかることを意味します。短い1週間のスプリントは、チームが2〜3か月でその高性能な状態に到達するのに役立ちます。もちろん、高いパフォーマンスを得るには、他にも必要なものがあります（カッツェンバッハとスミスによる「チームの知恵」を参照）。
• 他の人が述べたように、短いスプリントはフィードバックサイクルを増やします。1週間のSprintは、ソフトウェア開発または製品開発を行うほとんどのチームに最適です。フィードバックは主に、従来のUATプロセスの代わりとなるスプリントレビュー中に行う必要があります。
• 最後に、短めのスプリントは、頻繁な配信に対する組織の障害に対処するようチームに圧力をかけます。この圧力は最初は非常に不快ですが、計画、コンプライアンス、リリースなどを含む開発プロセス全体を改善するために不可欠です。

興味深いと思われるスプリントの長さを選択するための21のヒントと呼ばれる記事を書きました。

セレモニーには目的があります。目的を認識すると、オーバーヘッドではなく付加価値があることがわかります。

計画 -仕事に取り組むことだけでなく、チームメイトと協力する方法を理解することも。人々が彼らのスクラムチームのコラボレーションの欠如について不平を言うとき、私は問題の一部として彼らのスプリント計画を見てみたいです

レビュー -私たちが何を構築していて、まだ関連性があるかなどについて顧客からフィードバックを収集します。品質チェックとしても機能します。

回顧 -チームとして一緒に働く方法を改善します。

より深い目的を尊重することに力を注ぐと、オーバーヘッドの問題は通常なくなります。質問への最初のコメントで述べたように、式典は一般に直線的に拡大縮小されます。

このテーマについてもっと知りたい場合は、「スプリントの長さの選択」という記事があります。