とあるアジャイルチームのプランニング
この記事は「組織を芯からアジャイルにする」をテーマに活動するコミュニティ「シン・アジャイル」が運営する note マガジン「【ほぼ月刊】シンアジャマガジン Vol.3」に向けて執筆しています。
Vol.3 のテーマは「アジャイルなプランニングどうやってる？」。様々な手法やフレームワークが紹介されているふりかえり（レトロスペクティブ）とは違って、プランニングをどのように行っているか？という具体的な情報は意外と見つからないものです。
この記事では、自分達のチームがどのようにプランニングを行っているか？をありのままに・赤裸々にお伝えすることで、プランニングのありかた・進め方に困っている人のヒントになることを期待するものです。
自分達のチームと自分の役割について
自分が現在所属しているチームは3人の専任開発者 + PO 兼開発者の4名体制で、自分はそのうちPO 兼開発者を担当しています。イテレーション（スプリント）の期間は1週間としており、毎週火曜日にレビュー・ふりかえり・プランニングを実施しています。
チームではプロダクトバックログ、スプリントバックログ共に Miro で管理しています。
見積
毎週月曜日の夕方に、PO と開発者が集まり同期的にリファインメントと見積を行うミーティングを1時間行っています。そこではプロダクトバックログの上位から順番に PO から説明を行い、開発者に見積をしてもらいます。
リファインメントの一環ですので、開発者の意見を取り入れてその場でプロダクトバックログ（PBI）の見直しをしたり、場合によっては必要な情報が不足しているためにその場での修正・見積を断念することもあります。
見積はストーリーポイントを使った相対見積で行っています。現在、チームはリモート主体なのでプランニングポーカーのために firepoker という無料ツールを使わせてもらっています。
見積に関する細かい話はまた別の機会に。
プランニングの進め方
見積
月曜日のミーティングで時間が足りなかったために見積もれなかった PBI や、ミーティング後に追加したり修正した PBI がある場合に、まず最初にそれらの見積を行います。やり方は月曜日のミーティング同様です。
ポイント数目安の決定
まず直近数週間のベロシティ、つまり完了することができた PBI の合計ポイント数（の平均）を確認し、取り組むポイント数の目安をチーム全員で相談し、決定します。
ここではベロシティだけでなく、イテレーション期間中におけるメンバーのスケジュールも確認します。
祝日で稼働日数が減っていないか？
休暇を取る予定のメンバーはいないか？
隔週や月次で開催されるミーティング等で通常より開発に割ける時間が少ないメンバーはいないか？
直近のベロシティと、イテレーション期間中のスケジュールから取り組むポイント数の目安を決定します。次のステップで PBI を「とりあえず選ぶ」ための目安ですので、このポイント数をいくつにするか、という議論に時間を割くことはありません。目安ですので、最終的な計画はここで決めたポイント数よりも大きかったり、少なかったりする場合もあります。
PBI をとりあえず選ぶ
ポイント数目安を参考に、PO が PBI を上から順番にとりあえず選び、スプリントバックログ（カンバン）に移します。
この時点で無茶な PBI の組み合わせがある場合を除き、実現可能性などはあまり深く考えず、本当に「とりあえず」選びます。場合によっては、合計ポイント数が目安に設定したポイント数に対して ±1pt 程度の増減がある場合もあります。
タスクに分解する
PBI はあくまでストーリー単位であり、それはいくつかのタスクに分解することができます。PBI を実際のタスクに分解・細分化する目的はいくつかありますが、例えば次のようなものです。
PBI に対して必要な作業の解像度を上げる。
作業を細分化することで、プルリクの粒度を下げることに繋げる。
1つの PBI について複数人で分担することを可能とする。
場合によっては、この段階で見積時には気付いていなかった作業や懸念点が見つかることもあります。その影響度によってはこのタイミングで PBI のポイントを見積もりなおします。
この計画は達成できそうか？を確認する
一通りタスクへの分解が終わったら、スプリントバックログ全体を見通し、開発者全員で「この計画は達成できそうか？」を一斉にファイブフィンガーで表明します。
無理！😫
ちょっとヤバそう😢
五分五分🤔
イケそう😋
余裕！😆
この時点で明らかに達成が難しそうな場合は PO と相談し、PBI を減らしたり、入れ替えることを検討します。
フォーメーションを検討する
自分達のチームでは場合によってペアプロやモブプロを行うことがあります。週の途中で突発的に実施することもありますが、PBI やタスクの内容によってはこのタイミングで特定のタスクについてペアやモブを計画として組み込みます。
次に、各タスクについて誰が担当するかをすべてのタスクについて割り振っていきます。割り振る、といっても PO やリーダー的な存在が決めていくのではなく、あくまで開発者間で相談しながら決めていきます。
このタイミングで決めた担当者については、週の途中で変更することもありますが、この時点で各自が担当予定のタスクを決めることで、計画が達成できそうかどうかのジャッジがより正確になることを期待しています。
自分達のチームではこの「どうやるか」「誰がやるか」、つまり計画の進め方をフォーメーションと呼んでいます。
改めてこの計画は達成できそうか？を確認する
フォーメーションが決まったら、先程同様に開発者全員で「この計画は達成できそうか？」を一斉にファイブフィンガーで表明します。
実際に各自が担当する予定のタスクが明確になることによって、指の数が増えることが多いですが、この段階でも3以下が大半を占める場合など、計画の達成が難しそうな場合はフォーメーションの変更や PBI の削減、入れ替えを相談しながら行い、最終的に「達成できそう」と全員で合意ができるまでそれを繰り返します。
プランニングの所要時間
プランニングには毎週2時間を確保していますが、通常1時間程度で終わることが多いです。
感じている課題
現在、チームではこのやり方に一定満足しており、うまく機能していると感じている一方、課題も感じています。既にお気づきの方もいらっしゃるかもしれませんが、先に説明した「プランニングの進め方」ではスプリントゴールに触れていません。
スプリントゴールとは、スクラムガイド 2020 によれば次のように定義されています。
スプリントゴールはスプリントの唯⼀の⽬的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。スプリントゴールはまた、⼀貫性と集中を⽣み出し、スクラムチームに⼀致団結した作業を促すものでもある。
スプリントゴールは、スプリントプランニングで作成され、スプリントバックログに追加される。開発者がスプリントで作業するときには、スプリントゴールを念頭に置く。作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。
では自分達のチームではどうか、と言うと多くの場合「先頭の PBI が完了する」ことを意味するような、先頭の PBI のタイトルがそのままスプリントゴールに設定されることが多くなってしまっています。これでは、スプリントゴールが意図する柔軟性・一貫性・集中をもたらすことはできません。
この「スプリントゴールがうまく設定できていない」という点は課題に感じており、今後改善していきたいと考えています。
最後に（宣伝）
冒頭でもお伝えしましたが、この記事は「組織を芯からアジャイルにする」をテーマに活動するコミュニティ「シン・アジャイル」が運営する note マガジン「【ほぼ月刊】シンアジャマガジン Vol.3」に向けて執筆したものです。
他にも同じテーマで書かれた記事が投稿されているので、プランニングについて知りたい方はぜひ以下のリンクから記事を読んでみてください。
同コミュニティでは、一緒に活動してくれるメンバーを随時募集中です！Discord でワイワイしたい方、飲み会でアジャイルについて語り合いたい方など、興味をお持ちの方はぜひ下記のページへ！