はじめに
みなさん、スプリントは何週間で回していますか?
私の経験上、スプリントの長さはチームの開発効率やコミュニケーションに大きな影響を与えると考えています。
記事や文献を読み漁っていると、スクラム開発に慣れていないならまずは1週間、慣れてきたら2週間が良いというのをよく見かけます(バイアスあり)
じゃあ実際にそれは正しいのか。
本記事では私自身の経験をもとに、「1週間スプリント」と「2週間スプリント」のメリット・デメリットを比較し、どちらで回すのがベストなのかを考えてみます。
背景
とあるチームの例を1つ挙げます。
・自社でアプリケーション開発を行っている
・新しいプロジェクト・サービスを立ち上げたばかり
・デイリーには開発メンバー(テックリードやPO含む)のみ参加、PdMや他ステークホルダーは参加しない
このチームの特徴をもう少し深掘りします。
まず自社で開発を行っているため、SESや受託開発と比べると工数見積もり等は厳密でなくても良いと考えます(まあ会社によるとは思いますが..)。
また新しいプロジェクト・サービスを立ち上げたばかりなので、経験に則った見積もりを行うことが難しくなります。例えばプランニングで、「〇〇機能を開発するための工数は？」となっても、あくまで別プロジェクト・サービスでの経験をもとに推定を出すしかありません。
デイリーには開発メンバー以外不参加のため、開発の進捗やレビューを含めたステークホルダーとの意見交換の場は、スプリントレビュー、リファインメントくらいしかありません。
まずは1週間で回してみよう
メリット
(1)例え失敗しても、1週間で済むので挽回しやすい
(2)開発にスピード・リズム感が生まれる
(3)タスクの優先度を変更しやすい
(1)毎週行うレトロスペクティブ(振り返り)を行うことで、そのスプリントでの課題・失敗を振り返ることができます。
これにより、次のスプリントで何をすれば回避できるのかの対策を練れるので、そのまま失敗が続く、みたいなことが少なくなっていきます。
(2)開発した機能や成果物に対して素早くフィードバックが得られます。
開発者自身がスピードやリズム感を持って取り組めているという感覚を持つことができます。
(3)毎週タスクの優先度を変更できるので、例えプロジェクトマネージャやステークホルダーからの差し込みがあっても柔軟に対応することができます。
これは開発者も同様で、タスクを取り組んでいる最中に別タスクを差し込みたい(例えば、〇〇機能のリファクタリングを入れたい!など)となったときに、次スプリントに入れるといったことができます。
デメリット
(1)会議に費やす時間が増える
(2)長期的なタスクが進めにくい
(1)スクラム開発では主にデイリーMTG、スプリントプランニング、レビュー、レトロスペクティブ、リファインメントといった会議があります。
そのうち4つは1回/スプリントとされています。
1週間スプリントの場合、プランニング1h,レビュー1h,レトロスペクティブ30m,リファインメント1h,daily20*5mとすると、5h10m/weekをMTGに費やすことに。。。
実際はアジェンダ準備とかを含めると大体1営業日くらいかかる感覚はします。
(2)例えば開発に2週間くらいかかるような大きな機能とか、1スプリント内に消化できなかったりします。
また1週間ごとにステークホルダーに進捗を共有しなくてはいらないという感覚になることから、アウトカムに対するプレッシャーがでたり、他への取り組み(技術的負債や運用管理の改善など)に中々着手できないといったデメリットもあります。
2週間で回してみる
1週間で慣れてきた。じゃあ2週間でやってみよう。
メリット
(1)作業時間を多めに確保できる
(2)大きめのタスクにも取り組める
(3)スプリント期間内でタスク調整ができる
(1)スプリント単位で行うMTGが隔週になるので、その分仕様整理やコーディングに割く時間が増えます。コーディングが好きなエンジニアからすると嬉しいことですよね。
(2)1週間スプリントでは完了まで持っていけなかったような大きめのタスクにも取り組めます。
(3)プランニングで計画したタスクが早く終わった時に技術的負債を解決したり、終わってないタスクを開発メンバーでカバーできたりと、1週間スプリントに比べて柔軟に動けるというのも良い点かなと思います。
ただここで注意すべきはステークホルダーの差し込みも受け入れるということではなく、あくまでチーム内のタスクを調整するにとどめるということです。
デメリット
(1)フィードバックが遅れる
(2)タスクの優先度を変更しにくい
(1)レビューやリファインメントといった、ステークホルダーとの意見交換の場が隔週になることから、成果物に対するフィードバックが遅れたりします。
(2)特に自社開発に多いと思うのですが、市場や顧客のニーズが変化しやすいサービスだとタスクの優先度が変わりやすいです。
そういったケースにおいて、1週間スプリントに比べて柔軟に対応しにくいと言えます。
実際に起こったこと
ここからは経験談です。
自分はこれまで1週間と2週間のスプリントを経験しましたが、基本路線は
- まずは1週間でやってみる
- 慣れたら2週間
という感じでした。
スプリントに慣れてきた時にまず出る話題として、「MTG多くない..？コーディングする時間もっと欲しい!」があります。なら2週間で回そうと。
ただ2週間で回すと、
・プランニングで2週間分のタスクを計画しないといけないので、準備やMTG、見積もりに時間がかかる
・スプリント途中にタスクの優先度を変更したい!となった時に、タスクを差し込みづらい
といった課題も後々出てきます。
特に後者で、「じゃあタスクの差し込みを許せばいいじゃん!」って思う人がいるかもしれませんが、その場合スプリントゴールが達成できなくなり、スクラムで開発を回す意味が薄れてきてしまいます。。
実際、自分のチームでは2週間スプリントを続け、かつ差し込みタスクも柔軟に受け入れ、スプリントゴールを意識しなくなった「なんちゃってスクラム開発」となってしまいました。。
結局スプリントは何週間にすべきか
今までの自分の経験を踏まえて、
- 1週間スプリント
- (1)プロジェクトチーム立ち上げ時
- 新規メンバー(例:新卒、スクラム未経験など)にスクラムを慣れてもらうため
- お互いがどういうメンバーかを知るために、コミュニケーションの機会を増やすため
- (2)新規機能をガンガン開発しているようなチーム
- 成果物に対するレビュー機会を増やすため
- (1)プロジェクトチーム立ち上げ時
- 2週間スプリント
- (1)顧客やビジネス要件が比較的安定しているチーム
- スプリント中の差し込みタスクが少ないため、タスクの優先度を見直す機会が少ないため
- 細かい仕様検討や品質向上を考える余裕が生まれるため
- (2)機能改善,運用保守がメインのチーム
- リファクタリングや大規模なアーキテクチャの変更など、大きなタスクにも取り組みやすいため
- (1)顧客やビジネス要件が比較的安定しているチーム
がベストかなと考えています。
例えば自分のような「自社開発 + 新規機能をガンガン行こうぜ」スタイルで開発しているようなチームは、1週間で回すのが良いのかなと感じました。
さいごに
今回は自分の今までの経験をふまえて、スプリントって何週間で回すべきかについて考えてみました。
率直な感想。
ある程度フレームワークがあるとはいえ、その通りに実行するのは難しいですね(笑)
チームが置かれている状況、メンバーがどういう人かによっても変わってきますしね。
そのあたり、細かい部分はチーム内で話し合ってどうすべきかを都度お話しすることは大事だと思います。スプリント期間も含めてね。
本記事は１開発者である自分が感じたことをそのまま書いた記事になります。
賛否両論様々な意見があると思いますが、温かい目で読んでいただけると助かります。また本記事を読んでの感想・意見等あれば、遠慮なくコメントに記載していただけると嬉しいです！
参考記事