ギリギリまで見せちゃいます！JCBのスクラムイベント！

JCB デジタルソリューション開発部アプリチームの森口です。
アプリチームに所属しており、担当するサービスの開発・運用保守を行っています。

私の担当するプロジェクトではスクラムで開発をしています。
認定スクラムデベロッパー（CSD）研修を受けて、他社がどういうスクラムを実践しているのか個人的に気になったので、まずは、自チームのスプリント中の過ごし方を記事にしてみました。

はじめに

担当するプロジェクトでのスプリント期間は2週間になります。

スクラムイベントは水曜日にまとめて実施しており、スクラムイベント以外の時間は開発に注力しています。
イベントにはそれぞれタイムボックスを設定しています。

基本的にはリモートで活動しており、POを除くメンバーは常時GoogleMeetを接続しています。
ペアで作業する事が多く、作業中はペア毎でブレイクアウトルームに分かれて作業を実施し、イベント時だけメインのルームに集まってイベントを実施しています。

プロダクトバックログアイテム（以下PBI）、スプリントバックログアイテム（以下SBI）はJiraで管理しています。

スクラムメンバーはプロダクトオーナー（以下PO）、スクラムマスター（以下SM）、開発者で構成しています。
SM、開発者はシステム部門の人、POはユーザー部門の人になります。

デイリースクラム

参加者

SM、開発者

タイムボックス

15分

Jiraを使い作業の進捗状況や困っていることがないかを確認します。
また、進捗状況によってはスプリントゴールの調整を実施します。

チーム内共有会

参加者

開発者

タイムボックス

1時間

スクラムガイドにはない、チーム独自のイベントです。
対応したバックログをどう実現したかなどを対応者が共有し合う場となります。
スキルの平準化を目的とし、イベントを設定しています。

リファインメント

参加者

PO、SM、開発者

タイムボックス

1時間

PBIの優先順位や内容を確認をしたり、開発者が着手できるレベルまでPBIの内容の詳細化をしています。
開発者が着手できるレベルのPBIに対してこの場で見積もり（ストーリーポイント）を実施しています。
また、プロダクトゴールのすり合わせも適宜行っています。

Sprint中間報告会

参加者

開発者、（SM）

タイムボックス

1時間

デイリースクラムより詳細に進捗状況や困っていることがないかを確認します。
PBIの受け入れ基準（Doneの定義）の再確認を行い、満たしているかの確認もします。
受け入れ基準の未達成が原因で、Undoneになる事が多々あったので、独自に設定したイベントになります。

Dev内事前スプリントレビュー会

参加者

開発者、（SM）

タイムボックス

1時間

スプリントレビューの前日にスプリントレビューの予行を行い、デモの手順、内容の確認をします。
過不足があれば、デモ内容をこのタイミングで正します。
スプリントレビューは1時間のタイムボックスを設定しており、時間内で終わるかの確認も行なっています。

スプリントレビュー

参加者

PO、SM、開発者

タイムボックス

1時間

スプリントの終了時に、開発者がスプリント中に達成した成果物をPO向けに共有（デモ）を実施します。
チーム内の工夫として事前にデモ動画を収録しており、当日はデモ動画と口頭で補足をし、POに共有しています。
以前、時間内にスプリントレビュー時の予期せぬトラブルやデモの実施時間が長く、時間内に終わらない事が多々あった為、事前にデモ動画を収録しています。
デモ動画を収録する事で、トラブル削減に寄与しています。
また、状況によっては、スプリントレビューより前にPOにも確認してもらう事もできる為、当日のレビュー時間の削減に寄与しています。

レトロスペクティブ

参加者

PO、SM、開発者

タイムボックス

1時間

Whiteboards for Jiraというホワイトボードツールを使いレトロスペクティブを行なっています。
まず、前回のレトロスペクティブで出たアクション項目を振り返りを行い、達成できたかを確認をします。
その後、様々な振り返り手法を用いてスプリント期間中を振り返っています。
最近は、よこなーるという手法を使っています。
この場で出たアクション項目は次のスプリントで実践します。
開発が必要なものはPBIを作成することもあります。

プランニング

プランニングは2部構成で実施しています。

プランニング①

参加者

PO、SM、開発者

タイムボックス

1時間

POには予めPBIの優先度の入れ替えを実施してもらった上、プランニング①を実施します。
説明を必要とするPBIがあれば、POから説明してもらったりする事もありますが、リファインメント時に説明をする事が多く、さらっと進むことが多いです。
直近のベロシティや開発者のキャパシティ（スプリント作業可能な時間）を考慮して、優先順位順に並べたPBIをもとに次スプリントの開発スコープを仮決定します。

プランニング②

参加者

開発者、（SM）

タイムボックス

1時間30分

どのPBIにどのメンバーが取り組むかをプランニング①で決めた仮の開発スコープ内の全PBIに対して決めます。
また、開発者が開発しやすいサイズにする為、PBIからSBIを作成します。
どのPBIに着手するかは基本的には早いもの勝ちの挙手制で決まります。
ペアプロを採用しており、１つのPBIに対して２名立候補できます。

ペアや担当PBIが決定したら、各々分かれてSBIの作成とそのSBIに対する時間見積もりを実施します。
作成後に全員集合し、認識のズレを防ぐ為にSBIの共有を行い、認識のズレ等があれば、都度修正します。
最終的にメンバー内で合意が取れたら開発者のキャパシティを見積もりした時間を超えていないか確認します。
超えていない場合は、プランニング②は終了し、翌日よりスプリント開始となります。
超えていた場合は、開発スコープの見直しをPOに打診し、了承を得られたら、スプリント開始となります。