Sprint期間を1週間と2週間で検討してみた

この記事は「READYFOR Advent Calendar 2022」18日目の記事です。

READYFORでPdM兼エンジニアリングマネージャーをやっている ohata です。
今回はプロダクト開発を進めいている中で、SprintGoalが達成できない時期が続いた時にチームでSprint期間を見直し改善を進めた体験談を書いていこうと思います。
※READYFORでは厳密なScrumを行なっていませんが、ScrumイベントをベースにSprintを実施しています

どのように試したか

Goal達成ができなかった要因を振り返り(Sprint Retrospective)で話した結果、大きく2つの要因がありました。

チームの課題

- レビューには出せるがapproveまでが間に合わない
    - SP(ストーリーポイント)を消化できない
- 実装時に見積もりと大きくなる箇所が出てきて、計画されたissueが消化できなかった

今までは1週間Sprintで行なっていたので、単純に時間と余裕がないという意見が多くSprint期間を変更してみようということになりました。実施時にはどちらが良いかを判断する時期を決めず、うまくいかなかったら再度見直すスタンスでtryしました。

結果どうだったか

試してみた結果、今のチームには1Sprint1週間で設定するのが適しているということになりました。

2週間Sprintはどうだったか

結果的には2週間Sprintでうまく回らなかったわけではなく、2週間Sprintにしたことによりプロセス改善にチーム全体で取り組める余裕ができた結果、1週間でも回せるようになってきたというのが結論になります。

1週間Sprintに戻した理由

2週間Sprintでも大きな問題はなかったのですが、サイクルがうまく回ると1週間Sprintのメリットを大きく活かせる状態になりました。

1週間Sprintで良い点

- 突発的な優先度変更に対応しやすい
- SprintPlanningで設定したものが、チーム外の要素で崩されにくい
- Goal未達成時のリカバリーを素早く検討できる

プロダクトを継続的に運用していくと、日々の問い合わせや計画にない割り込みタスクなどは一定発生します。1週間であれば優先度を依頼元と調整しやすく、コミュニケーションコストも少なくなります。どうしても必要なものは対応が必要になりますが、優先度の高いものだけの対応になるので負荷を抑えることができます。
また1週間Sprintだと緊急が発生しないSprintも存在します。

改善した点

今回原因として考えられたレビュー時間効率化と計画の差異については、発生毎に対応しているため効率が落ちているのではないか？ということが振り返りで出てきており、対策を検討することになりました。

ContextSwitchの話

一般的にコンテキストスイッチが発生すると以下のような効率悪化があると言われています。
※ ここでいうContextSwitchは別の作業への切り替えの事とします

プロジェクト数	プロジェクトあたりの稼働時間	作業ロス
1	100%	0%
2	40%	20%
3	20%	40%
4	10%	60%
5	5%	75%

プロジェクトをそこまで兼務することはないので、この数値が全てに当てはまらないとは思いますが、作業レベルでのコンテキストスイッチが発生することはありそうです。

- 問い合わせ対応 (調査依頼)
- 不具合対応
- レビュー対応 (チーム内)
- レビュー対応 (チーム外)

上記については、無くしていけるものでもなく一定発生するべきなので、優先度をつけて対応していくことが現実解としては正しいと思います。専任プロジェクトでもコンテキストスイッチが多く発生する状況があると思っていて、チーム内で解決できることとしては ContextSwitchの回数を減らす 事だと思いました。

ContextSwitchの回数を減らすため

選択と集中の時間を作るため、都度発生するイベントをなるべく定期に組み込んでしまおうというアプローチを取りました。

- レビュー時間の定期的な確保
- Scrumイベントでの解決

ScrumイベントによるContextSwitchの改善

一定の作業の切り替えが必要だったとして、コンテキストスイッチの回数が増える原因は 予定・予想していなかった作業 というのが大部分を占めていると思います。
プロダクトチームとしては開発のみならず、運営もしている訳なので日々どこから問い合わせなどが来るようになります。それにプラスアルファで自分のプロジェクトに関する不確定要素を気づいた時点で話すというのは非常に効率が悪いことになります。そこでScrumの定期イベントのスケジュールを工夫してなるべくコンテキストスイッチの回数を減らすようにスケジュールを検討するというのは１つの解決案だと思います。 (現在進行形)

Scrumイベントにかける時間の割合

ここでScrumで定義されているイベントの時間割合を認識していきたいと思います。

1人あたりの1週間の総時間 8 x 5 = 40時間とします
1週間SprintでのScrumイベント時間

イベント	時間(max)	実施タイミング
デイリースクラム	1時間	定期
スプリントプランニング	2時間	定期
スプリントレビュー	1時間	定期
スプリントレトロスペクティブ	1時間	定期
バックログリファインメント	4時間	任意※1
計	9時間

• ※1 バックログリファインメントは必要に応じて時間を取ることになりますが、10%以下で計算することが推奨されています。現在のチームではリファイメントの重要性をレトロスペクティブで確認できたのでmax時間で計算しています

イベント全体で 9時間かかるので 1Sprintでイベント以外に利用できる時間は31時間になります。
さらにここから要件共有や組織内のイベント、他チームのレビュー時間を見積もるとさらに減ってしまいます。
Scrumイベント外にかかる時間を3時間として計算すると
40 - 9 - 3 = 28時間 が開発に利用できる時間になります。
開発に使える時間が少ないように見えるかもしれませんが、開発に100%集中できる状態を作った方が最終的にはGoal達成率が上がったため非常にバランスが良いと感じています。

Scrumイベントをスケジュールに適用した例

• イベントを固めたパターン
  

• イベントを分散させたパターン
  

上記では月曜にScrumイベントをもってきていますが、なるべく月曜・金曜にScrumイベントを持ってくるのは避けた方が良いと思います。月・金は祝日になったり、連休をとる方が多い傾向があるため、ここはチームメンバーや運用状況などによって相談できると良いかなと思います

まとめ

Scrum原則の [守・破・離]をベースにまずは[守]の部分をしっかり定着させ、そこから飛躍することが大事だなと改めて感じました。定着させること自体は難しいとは思いますが、チームで考え試行錯誤した結果、迷いなくイベントを徹底していく意識もできたのでチーム運営を選択と集中してやっていけるような経験ができたのはとても良い経験でした。