はじめに

この記事では、23年に新卒エンジニアとして入社し、新卒1年目からスクラムマスターを任されてからの8ヶ月間を振り返り、試行錯誤してきたことについてお話ししたいと思います。最後まで読んでいただけると幸いです。

スクラムで使用していたツール

Backlog: 進捗管理のためにカンバンボードとして使用
jamboard: 振り返りでFun Done Learnを行う際に使用
gather: チームでスクラムイベントを行う場として使用(ポイント付もここで行っていました)
GitHub: いうまでもなく、コード開発で使用

スクラムマスターになる前のチームの課題

開発者として3ヶ月ほどチームで活動し、以下の改善点があると考えていました。

スクラムマスターとプロダクトオーナーが同じ人であり、負担が偏っている
チーム内で新しいチケットを切る人が固定化されている
ベロシティがスプリントによって差があり、消化予定ポイントが見積りづらい
GitHubのPRにBacklogのチケットを貼っているが、リンク切れ等で背景が追えなくなってしまう

皆さんのチームでも似たような課題・悩みがある方も多いのではないでしょうか？
私はスクラムマスターを引き受けるのであるならば、この課題を少しでも解決したいと意気込んでいました。

スクラムマスターとして改善した点

では早速私がこの数ヶ月で挑戦したこととその結果について記述します。

チケットの切り方を変えたお話し

チームのリーダーが主体となりチケットを切っていた方法を見直し、miroへ移行しました。ユーザーストーリーを作成した上でチームメンバーと話し合いながらチケットを切るようにしました。この際、これまでチケットを切っていた方にお願いして、細分化までは行わないようにしてもらいました。

メリット:

チームメンバーが背景を知った上でチケットを取ることができるようになったので、その後の個別の相談が少なくなった
チームの誰でもユーザーストーリ経由でチケットを切って良いという感覚が生まれ、チケットを切る偏りが小さくなった
チーム内の負担が分散された

デメリット

スプリントプランニングに今まで以上に時間がかかるようになった(始めた当初は約1.5倍ほど時間がかかるようになった)
ユーザーストーリー上のチケット(以下プロダクトバックログ)とBacklog上のチケット(以下スプリントバックログ)の2重管理となり、スクラムマスターとしての雑務が増えてしまった

ベロシティの計測方法を変えたお話し

これまでは、スプリントの振り返りの際にスプリントで消化したポイント×キャパシティをベロシティとして次のスプリントで使用していましたが、振り返りで消化したポイントと実際のポイントに乖離がある場合に申告してもらい、その原因を話し合った上でポイントを再調整する作業を入れました。また、ベロシティも3回分のスプリントの平均ベロシティとすることで、より実態に近いベロシティを算出するようにしました。
メリット

スプリント毎の消化予定ポイントのブレが小さくなりチーム内でこの指標に対する意識が強くなった

デメリット
計算が少し面倒になるだけで、他のデメリットはなし

BacklogをやめてGitHub Actionsへ移行したお話

スプリントバックログをGitHub Actionsへ移行しました。

メリット

Backlogのリンク切れがなくなった
GitHubのワークフローを使用することで、少しボードの管理が楽になった(自動アーカイブやDoneへのチケット移動など)
スプリントでのグラフの可視化をより自由に作成できるようになった（例えばスプリント毎にどのリポジトリに対するチケットが多かったのかを可視化し、振り返りで使用することができるようになった）

デメリット

親子課題がGitHub Actionsの基本機能ではないなどの制限はありますが、私のチームではこの機能をほとんど使用していなかったのでほとんでデメリットにはならなかった

他チームのスクラムマスターと意見交換をする機会を作った

スクラムマスターをしながら気づいたのですが、同じ会社であってもスクラムチームが異なると、それぞれで独自のスクラムの形を模索し、それに対する情報の共有がありませんでした。そこで、数ヶ月に1回各チームのスクラムマスターが集まり、現状のチームで抱えている課題について話し合う場を設けました。

メリット

チーム内で悩んでいることは大抵どのチームでも共通で、それを共有することでより迅速に問題解決が行える
スクラムをする上で困ったことを気軽に相談できる場ができる

最後に

この数ヶ月、私が試行錯誤しながらスクラムマスターとして悪戦苦闘してきたことを書きましたが、トータルでは当初の課題を解決できたのではないかと思います。
また、スクラムマスターとして常に意識していたのは「自分のチームにとって最善の方法は何か」ということでした。もちろん、教科書通りのスクラムであればアンチパターンな部分もあるかもしれませんが、現状を踏まえた上で改善を行わないと本末転倒な結果を招きかねません。チームは生き物のように常に動いているので、今後もその変化を捉えながらスクラムマスターとして邁進していきたいと思います。