はじめに
- 概ね、ryuzeeさんが説明されてるので、それ以上いうことはない気はする。
- それ以外のちょっと極端な事例をいくつか紹介するので、みなさんがスプリント期間を考える際のインプットになればいいなと思ってまとめています。
ベースの考え方
最初は1週間スプリントがお勧め
ryuzeeさんが1週間をお勧めする理由（ただし2018/02の記事なので最新の思いは変わってる可能性あり）
- レトロスペクティブ（ふりかえり）が頻繁にあるので改善が進む
- 計画の精度が高くなる
- 例え失敗しても一週間で済むので実験しやすい
- ベロシティの数字がすぐ出るのでやる気になる
- 中だるみする余裕がない・リズムがよい
- 一週間で収まるサイズのプロダクトバックログアイテムにするので明確な完成を定義しやすい。従ってプロダクトオーナーの受け入れを取りやすい
- スパイクが必要なプロダクトバックログアイテムが明確になる
- プロダクトオーナーが変更を我慢しやすい
- ごまかしが効かない
詳細は以下にも記載されているので、もう少し詳しく理解したい場合は見てみるのが良いかと。
スプリント期間を短くする/長くするのが良いケース
概ね解説編に書かれているのをサマリしたような形になりますが・・・
個人的に学習した範囲も補足した上で自分の理解をまとめておきます。
短くするケース
- 現状の計画の精度が低い
- 現状のスプリント期間分の作業をばらし切ることができない。（作業の見通しが立っていない）
- バックログアイテムの受け入れ条件（完了条件）を明確に定義することができない（何を持って終わりとすればいいかわからない）
- 該当のスプリント期間ちょうどで終わると思えずバッファを多めに積みがちになっている
- 手戻りリスクが許容できないレベルの影響・発生確率・発生頻度
- 現状のスプリント期間分の手戻りが許容できない（例えば、3ヶ月のプロジェクトで1ヶ月スプリントだった場合、万一手戻りした場合、PJ影響が大きすぎます。
- スプリント期間中であっても要件の変更をせざるを得ずスプリント期間中の手戻りが発生する
- フィードバックサイクルが上手く回っていない（主に以下のような理由で）
- 現状のスプリント期間で得られる情報量が多すぎるせいで振り返りに時間がかかりすぎている
- 振り返りの結果対処すべきアクションが多すぎてどのアクションも散漫になっている
- 一度に行う改善アクションが多すぎて何が効果を出しているのかわかりづらい
- チームがスクラムに慣れていない
- 次のイベントまで期間が空きすぎていて、スクラムイベント自体の理解が進まない。
- POがチームの成果物を把握できない
- チームの成果物の量が多すぎて把握できない
- 作業期間が長すぎて成果物量が妥当なのか判別できない
長くするケース
短くするケースと逆なだけなので割愛。
実際の例
自分の例。
- 初期3ヶ月くらいは１週間スプリント。（3ヶ月は目安であって固定ではない）
- 一旦2週間スプリントにして様子を見る。
- 問題なさそうならそのまま2週間を継続。まずそうなら1週間にする。
あんまり3週間とか4週間とかは使わない。1週間か2週間かって感覚。
ちょっと極端な事例（2日スプリント/15分スプリント）
こういう極端なチャレンジはなかなか受託開発の現場ではやりにくいところはあるんですが、事例としてちゃんと理解しておくことで手札が増えてる感覚はあります。
こういうケースを公開していただけるのは本当にありがたい限り・・・
2日スプリント
15分スプリント
次回予告
ここ２日ほど受託関係ない話が続いてましたが、次回からは受託絡みに戻ります。
受託アジャイルの体制を考えるときに抑えておくべきこと（今まとめ始めてますがポイントが思ったより多すぎるので、分割して記事にしていきます）