チーム規模が変動するチームでスクラムマスターとしてやってきたこと

お久しぶりです。シニアエンジニアの @sakebook です。今回私がスクラムマスター(以下SM)として所属するチームで、SMとして、およびチームで取り組んできたことなどを共有します。

背景

他社事例なども見聞きするなかで、今まで何をやってきたのかを共有することはそれなりに誰かの役に立つことがあると思ったのでこの度まとめました。

前提

この手の話を見聞きする上で前提が異なっていると解釈しにくいので、私たちのチームについて説明します。

チームには業務委託や副業の方、つまり週5稼動ではない人たちもいました。
最大でエンジニアは10人強いました。出入りは数ヶ月単位で発生していて、最小は5人です。
PBI管理にはJIRAとNotionを併用しています。
1スプリントは2週間です。
チームはフルリモートです。

リファインメントの整理

スプリント計画で時間を押してしまうことが多く、リファインメントが慢性的に足りていないようでした。

リファインメントは30分x4で週に2時間の枠だったのですが、30分x8の4時間の枠にしました。

スクラムガイドでは作業時間の10%以下にすることが多いとあったので、その最大まで枠を確保しました。

初めはチームからも「多いのでは？」という声もあったのですが、やってみると「今までむしろリファインメントが足りていなかった」と感じる声も上がって、今までよりスプリントゴールへの自信度があがりました。毎回実施するのはなく、不要な時はスキップしたり柔軟に対応しています。

詳細見積もりの分離

リファインメントで、詳細が曖昧な部分、または実現方法が複数あって決めきれない場合などに話しきれないことが度々発生していました。これはストーリーポイントを見積もるタイミングがリファインメントしかないとチームで受け止めていて、なるべく正確に見積もろうという意識から発生しているようでした。

そこで、詳細見積もりの時間を枠として設けました。目的は見積もったPBIおよび見積もるPBIのストーリーポイントの精度を上げることです。こちらもリファインメントと同じだけ確保していますが、リファインメントとの違いとして次の特徴があります。

POは参加しなくても良い
チームも必要な人のみで話す
チームが不要と思ったら予定を削除できる

詳細見積もりで調整ができる前提で、リファインメントでは詳細が曖昧な部分があったとしても、それによってストーリーポイントに変動が起きそうかどうかに着目してもらい以前に比べて気軽に見積もりができるようになりました。

また、結果的にスプリント計画でやっていた内容も分離でき、スプリント計画ではプランニングに集中できるようになりました。

今のチームではストーリーポイントの数字にはフィボナッチ数を採用しています。

ワーキングアグリーメントとストーリーポイントの基準の定期的な見直し

前提にある通り、チームの変動が度々ありました。チームへの受け入れドキュメントの一つとしてワーキングアグリーメント(以下WA)を活用しました。ストーリーポイントも、チームが異なれば基準が変わるので、どんなPBIだとストーリーポイントがどの程度になるのかを参照できるようにドキュメント化しました。それぞれクォーターごとに見直しイベントを設定し、更新しています。

別途スプリントレトロスペクティブでWAに採用したいことがあったり、見直したいという声があればクォーターを待たずに更新しています。