スプリント期間は短い方がいい?1週間スプリントをやってみて
TAIANでは半年ほど前からスクラム開発を導入しています。
一般に、スクラム開発の期間は1〜4週間くらいが多いと思いますが、その中で導入当初はスプリント期間を1週間としていました。
やってみて思ったことや感じたことを振り返ってみます。
スクラムを導入してみてについては以前こちらで川平さんが書いています。
気合いと根性で回してた開発チームが、スクラム導入で"本当のチーム"になった話
1週間スプリントをやるメリットは?
ビジネスサイドに価値を届けやすくなること
スクラムにはイベントが色々と設定されることが一般的ですが、それぞれビジネスサイド視点で以下のような役割があるかなと思っています。
- バックログリファインメント
要望の吸い上げ、解決手段の検討、優先順位付け - スプリントプランニング
ビジネスサイドが求める成果物の計画 - デイリースクラム
スプリントの成果物をビジネスサイドに確実に届けるための進捗管理 - スプリントレトロスペクティブ
チームの生産性を上げるための振り返りと Try の設定 - スプリントレビュー
スプリント単位でリリースされる機能の共有
上記の図のように、バックログリファインメントとスプリントレビューがビジネスサイドに対してのエンドポイントの役割を果たしてくれることで、導入前に比べてコミュニケーションが取りやすくなったなと感じています。
このサイクルを高速でやることでビジネスサイドの要望改善を早く解決できるようになったと感じました。
1週間スプリントをやるデメリットは?
スクラムイベントに時間を取られること
上記のメリットを享受するためにはスクラムイベントが不可欠なのですが、これが結構時間がかかります...
TAIANでは導入当初、以下のようにイベントの時間を割いていました。
- バックログリファインメント
1時間/週 - スプリントプランニング
1.5時間/週 - デイリースクラム
15分/日 - スプリントレトロスペクティブ
1時間/週 - スプリントレビュー
1時間/週
イベント時間は合計約6時間/週
また、スプリント内で1.5日間テストの期間を設けていて、この期間はテストで上がってきた修正を行います。
そのため、純粋に開発に充てられる期間は3日/週でした。
スプリント期間の決め方は?
プロダクトの状態により、頻度と速度どちらを優先するかで決める
上記のようにスクラムイベントとテストで2日とすると、週あたりの開発期間は以下のようになります。
スプリント期間を長くするほど開発期間は長く取れそうです。(4週間以上にしても4週間スプリントと実質開発期間は大きく変わってこないので、1〜4週間が主流なのかも?)
スプリント期間 | 開発期間/週 |
---|---|
1週間 | 3日 |
2週間 | 4日 |
4週間 | 4.5日 |
4週間以上 | 5日に近似していく |
これを踏まえると、プロダクトの状態から以下のようにスプリント期間が決められそうです。
プロダクトの状態 | 重視するもの | スプリント期間 |
---|---|---|
課題が特定できていない | リリース頻度 | 短くする |
課題が特定できている | 開発速度 | 長くする |
TAIANの場合はどうした?
スクラム導入前はとにかくリリース頻度を上げて要望を集めるのが大事だと思い、導入当初は1週間スプリントにしていました。
しかし、バックログがかなり溜まってきていて、1週間で完了できるバックログよりも上がってくるバックログの方が多いという現状でした。
要望も溜まってきていて、現在は開発速度を上げるために2週間スプリントに切り替えてみています。
ただ、導入当初に1週間スプリントをやってみて、スプリントレトロスペクティブを多く回せたのはよかったなと思っています。
2週間スプリントが合いそうということも、振り返りの頻度が高かったからこそ気づけたのかなと思っています。
最後に
今回あげた観点はほんの一側面で、それぞれのスプリント期間のメリット、デメリットは他にも色々あるかと思います。
例えば、
- スプリントレトロスペクティブを多く実施できるので、短い方が生産性を磨きやすくなる
- リリース間隔が長い方がエンジニアの心理的安全性が高まる
- テスト期間を減らして、短いスプリントでも開発期間を長く取る
etc...
事業や組織のフェーズに合わせて、自分たちに合うスクラムのやり方を探していくのが大事なのかなと思っています。
We are hiring!
TAIANでは、このような開発・技術・思想に向き合い、未来をつくる仲間を一人でも多く探しています。少しでも興味を持っていただいた方は弊社の紹介ページをご覧ください。
Discussion