スプリントの期間を 1 週間から 2 週間に変えてよかったこと

はじめに

こんにちは。
Circuit X リプレイスチームでプロダクトオーナーをしています、佐藤です。

僕が所属するチームではスクラムでプロダクトの開発をしています。
最近、スプリント期間を 1 週間から 2 週間に変えたみたので、実際どうだったのか書いてみたいと思います。

そもそもなぜ 1 週間にしていたのか

リプレイスチームでは約 1 年半、スクラムで開発をしているのですが、ずっと 1 週間で回していました。
僕が入社した時にはすでに 1 週間で回していましたが、

• 当時はスクラムに慣れていないメンバーがほとんどだった

• スプリント期間が短い方が早いサイクルで改善を実行できる

• 差し込みが発生しても、次のスプリントですぐ対応できる

というのが主な理由で 1 週間にしていたと理解しています。

1 週間スプリントで抱えていた課題

僕自身もスクラムは未経験のため、慣れるのに精一杯で、スプリントの期間にまで目を向けることができませんでした。
しかし、スクラムへの理解度が高まったことで、以下の課題を実感するようになりました。

• 全社的なスプリント期間は 2 週間（2 週間に一度リリースを行う）なので、他のチームの開発リズムとズレる

• スプリントプランニングからスプリントレビューまで余裕がなく、常に慌ただしい

• バックログリファインメントなどのミーティングで開発チームのスケジュールが埋まってしまい、まとまって開発できる時間が取れない

• 「リリースしたい機能の合計見積もりポイント > ベロシティ」のため、1 スプリントで機能を作りきれない

• それに伴い、スプリントゴールが「⚫︎⚫︎（機能名）の開発を可能な限り進める」のようなふんわりした感じになってしまう

• その結果、スプリントゴール達成意識の希薄化につながる（恐れがある）

メンバーもスクラムに慣れているので問題ないだろうと、2 週間にしようと開発メンバーに提案しました。
そして、2 スプリントだけ試験的に回してみて、1 週間のときと比較し、戻すか 2 週間スプリントで運用するか決めようという運びとなりました。

ちなみに、スプリントの期間を伸ばすのではなく、開発スコープを削ること（機能を落とす）で課題を解決する方法も考えられますが、リプレイスでは大胆に開発スコープを削るのはかなり厳しいです。

他にも、期間は変えずに課題解決できそうな打ち手は考えられると思います。
しかし、期間を延ばすことで解決できるのであれば、一番簡単なアプローチだと思っていたので、やってみようとなりました。

2 週間に変えてみて…

よかったこと

• 期間が伸びたことで、開発に集中できる時間を確保できるようになった

• 1 スプリントで機能を作り切れるようになった

• スプリントゴールを「⚫︎⚫︎（機能名）をリリースする」といった明示的なものに設定できるようになった

• スプリントゴールの達成が間に合うか怪しくなったら、どのプロダクトバックログは切り捨てるべきか議論できるようになった

スプリントレトロスペクティブであがったよかったこと

よくなかったこと

• スプリントの開始直後と終了間際はスクラムイベントでスケジュールが埋まってしまい、かなり忙しい

• 差し込みで対応したいタスクが発生したら、着手まで 2 週間は空いてしまう

• スプリントレビューでデモする内容が 2 倍になるので疲れる

スプリントレトロスペクティブであがったよくなかったこと

結果どうしたか

2 スプリント回してみて、メリットが大きいと感じたため、2 週間スプリントで運用してみようとなりました。

1 週間のときに抱えていた課題はスプリント期間を 2 週間にしたことで解決できたかなと思います。

記事執筆現在、2 週間スプリントで回してみて 4 スプリント目に突入しています。
スクラムイベントが 2 倍になったので、スプリントの開始と終了間際はかなり体力的に疲れますが、徐々に慣れてきました。
バックログリファインメントやミーティングを入れるときは、午前に集中させる、などもしつつ、だいぶ開発に集中できるようになったと思います。

過去にスクラムイベントでどんなことをしているのかを紹介した記事を公開させていただきましたが、今度は、1 スプリントに焦点を当てた開発チームのスケジュールとかもご紹介できたらと思います。
気になったら、下記の記事もぜひご覧になってください！