今年も本当にいろいろありました

が、エンジニアとしての１番の出来事は、当社社長からの「スクラムマスター、頼むわ！」です。(今までスクラム開発すら未経験)
SCRUM BOOT CAMPを読み込んで、「スクラム開発、完全に理解した」となりましたが、当然、すんなりうまくいくわけがなく。。。
試行錯誤しながらある程度、うまく回りつつある様な感じになったので実際に効果が実感できるスクラムイベントの工夫をまとめていきます。

イベント名と説明は「スクラムガイド™」より抜粋しています。(URL)

ちなみに弊社で使っているツールは、Azure DevOpsです。使い方はこちらにまとめています。

スクラムイベント

スプリントプランニング

説明(抜粋)

スプリントプランニングはスプリントの起点であり、ここではスプリントで実行する作業の計画を立てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。
プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の人をスプリントプランニングに招待してもよい。

工夫したこと

事前準備

事前にリファインメントを通じて、PBI(Product Backlog Item)を最新の状態にしておく。

仕様や受入条件についても同様。これによって、プランニングする時に「あれ？これ何だっけ？」とならずに、ストーリーポイントをつけることに集中できます。
リファインメントの前にPBIの上位項目を開発チームが目を通しておく。

リファインメントの時間に効率的に質問ができるし見落としや矛盾も少なくなりますね。

プランニング中

ゲーム性を大事にする。

当社では、Azure DevOpsのEstimateを使ってプランニングポーカーをしています。この形式は全員が気軽に自分の思うストーリーポイントを出せるのでとても良いです。
PBIをタスクに落とし込む時に、PBI毎にファシリテータを輪番制にする。

特定の誰かが仕切らないようにしたのは良かったです。最初はスクラムマスターが全部仕切ろうとして、途中で息切れしてしましました…プランニング中の緊張感を保てますし、いろいろな視点での指摘やアイデアが出るきっかけにもなります。
PBIを実際にタスクに落とし込んだら、一度、次スプリントのいつ(何日)に何が終わりそうかを共有する。

祝日や会社のイベントがあった時に、キャパシティ設定の誤りに気づくきっかけになります。

デイリースクラム

説明(抜粋)

デイリースクラムの目的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。
デイリースクラムは、スクラムチームの開発者のための 15 分のイベントである。複雑さを低減するために、スプリント期間中は毎日、同じ時間・場所で開催する。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する

工夫したこと

スタンドアップミーティングにする。

これは広く言われていることですね。時間を短く保つだけでなく、立ち上がる事で円陣を組むかのような妙な一体感が生まれます
DSの司会は輪番制にする。

毎日、DSの司会は開発者内で変更します。こうする事で、情報の共有が「なぁなぁ」になってしまうことを防ぐことができると思います。
バーンダウンチャートやスプリントゴールに関する話題をする。

各自に対する、「何をやったか？」・「何をする予定か？」・「障害は何か？」を聞くだけではなく、チーム全体の状況を共有しましょう。全員、DSで「困っていることはない」のに進捗が思わしくないと言った状況を防ぐことができます。

スプリントレビュー

説明(抜粋)

スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。
スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う。

工夫したこと

CI/CDをしっかり作って事前の準備の手間を少なくする

開発者がPRをした時に、デモ環境へのデプロイなどを自動ですることでレビュー前の開発者による検証などがしっかりできます。レビューの時にワタワタしないので無駄な時間が削減できました。(これは工夫というより当たり前か…)

スプリントレトロスペクティブ

説明(抜粋)

スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。
スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。
スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発生したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。

工夫したこと

事前に振り返るためのデータをまとめておく

こんな感じのテンプレートを使ってデータをまとめています。特にうまくいかなかった時に、何がまずかったのかがすぐにわかります。(差込が多かったのか、プランニングが間違えていたのか、etc…)ここから見えてきたProblemやTryは適切なものになりやすい印象です。

- 完了タスクの実際の作業時間合計はXX時間でした🎉
    - プランニングで漏れていたタスク(unplanned)の完了タスクの合計時間はX時間でした。
    - 想定した見積もり時間と実際の作業時間のの差の合計は**X時間**でした。
    - 差込みで発生した当プロジェクト以外のタスクは、X時間でした。
- 予定通り完了したEffortの合計はXXでした。次スプリント以降持ち越しのEffort合計はXです。

終わりに

スクラム開発はチーム毎に様々な形があると思います。なのでこれら全てを適用する必要はないでしょう。
ただ、もし参考になりそう、or 面白そうな施策だなと思ったら、試してみるのはアリですよ！お悩みのスクラムマスターはぜひ、お試しくださいませー。