[スクラム]スプリントプランニング・スプリントバックログ・スプリントの定義と運用事例（2024 Advent Calendar 5日目）

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の5日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

本記事ではスプリントプランニング、スプリントバックログ、スプリントの定義と自分たちのプロジェクトでの運用を紹介します。

スプリントプランニング

スプリントプランニングの定義

スプリントプランニングは、次のスプリントで実施することをプロダクトオーナーとエンジニアが話し合って決める活動です。着手するアイテムやタスクはプロダクトバックログ上から選択をします。プロダクトバックログは常に優先順位でアイテムが並べられているためです。

次のスプリントで着手するアイテムの量は過去の実績に基づいて決めます。直近2回のスプリントで消化したポイントの平均（速度という意味のベロシティと呼ばれます）と同程度にすることが一般的です。仮にベロシティが20ポイントであればプロダクトバックログアイテムを上から順にポイントの合計が20前後になるまで選択します。次のスプリントで実施するアイテムを集めたものをスプリントバックログと呼びます。自分たちのチームではアイテムを選択することを「（スプリントバックログに）アイテムを積む」と呼んでいました。

スプリントプランニングでは、チームの目線を揃えるために次のスプリントで達成するべきことをまとめたスプリントゴールをいくつか作成します。スプリントゴールを作ることで「このスプリントはこの分野に注力する」という意識をチームで共有できます。

もしプランニングの際にアイテムのポイントが適切ではないと不安に感じたら、一度戻ってリファインメントを実施しましょう。またポイントを振り直したり、アイテムをスパイクと実装タスクに分割した後にプランニングを再開すればスプリント開始後に「思ったよりポイントが大きくて完了しきれない」と焦ることはありません。

スプリントプランニングの運用

スプリントゴールの設定

スプリントプランニングでは、そのスプリント中に達成するアイテムをプロダクトバックログから優先度順に選択します。自分たちのチームではアイテムを選択した後にスプリントゴールを3つか4つほど設定していました。

本来はスプリントゴールを先に決めてからアイテムを選択するのかもしれません。しかし、アイテムを先に選択することでどこまでやれるのか見通しが立つためこのやり方に落ち着きました。

（スプリントゴールの画像）

スプリントバックログを見ればそのスプリントで何に着手するか明確だから、スプリントゴールの設定は不要だと考える人もいるかもしれません。しかし、スプリントゴールを設定しないと「チームでゴールを達成する」という意識が薄れてしまい、助け合いの精神が希薄になってしまいます。開発者が「自分がアサインされたタスクを終わらせればそれでいいのだ」という考え方になってしまうのです。

自分たちのチームではスプリントゴールにも優先順位をつけました。すると思わぬ効果がありました。一番優先順位の高いゴールに関係するアイテムを誰か1人ではスプリント内で達成できないと気づいた時、それより優先順位の低いアイテムに着手していた別のメンバーが「自分のアイテムは優先順位が低いので一旦着手を中止して、一番優先順位が高いゴールのアイテムを自分もやります」と救いの手を差し伸べたのです。

チームでゴールを達成する意識を全員が持ち、アイテムの着手順を自律的に組み替える意思決定をスムーズに行う体制を作れることがスプリントゴールの効果なのです。

バーンダウンチャートの設定

アイテムの消化ペースが順調かどうかを確認するために、自分たちのチームではスプリントプランニングの中でバーンダウンチャートを作成しました。バーンダウンチャートとは右肩下がりのチャートです。スプリント内で消化するポイント数を初期値として、日が経つごとにポイント数が減るチャートを作りました。

（バーンダウンチャートの画像を持ってくる）

例えば、次のスプリントの消化予定のポイントが20だとします。2週間のスプリントで営業日が10日あれば1日の消化予定ポイントは2です。初日は20ポイント、翌日は18、その翌日は16、そしてスプリント最終日2、スプリントが終わったら0とします。これを予測ポイント数と呼びます。

デイリースクラムの最後にそれまで消化したポイント数を計算し、バーンダウンチャートを更新して予測消化ポイント数と比較します。乖離が大きければその理由をみんなで探します。自分たちはスプリントが順調に進んでいるかどうかを判断する材料としてバーンダウンチャートを活用していました。

リリース直前のスプリントプランニング

リリース1ヶ月前ごろから、リリースまでにやることとリリース後にやることを振り分けました。リリースまでに終えなければならないアイテムのポイント数を合計して過去のベロシティを元にリリース日を算出し、チーム外の人にリリース予測日を共有していました。

スプリントバックログ

スプリントバックログの定義

スクラムにおいて、スプリントバックログは作成物です。スクラムにおける作成物とは、スクラムイベントを実施すると出来上がっている物です。スプリントバックログはスプリントプランニングの中で、プロダクトバックログから選んだアイテムをまとめたものです。プランニングの完了と同時にスプリントバックログの作成が完了します。

スプリントバックログの運用

スプリントバックログには、スプリント中にチームが取り組むアイテムが並んでいます。自分たちのチームでは、Figjamでプロダクトバックログアイテムもスプリントバックログアイテムも作成していました（今だとGitHub Project上に作ると思います）。このため、チーム外の人が見ても次のイテレーションでどのような成果物が出てくるかが一目瞭然でした。スクラムの三本柱である透明性が担保されていたのです。

スプリントバックログはデイリースクラムで全員が毎日チェックします。

（スプリントバックログの画像）

スプリントの実施

スプリントの定義

スプリントは1~4週間の周期（イテレーション）で実施するものとスクラムガイドに定義されています。スプリントプランニングを終えてスプリントバックログを作成してからスプリントを開始します。スプリントはあくまで入れ物であり、何をするかはチームや開発フェーズに応じて柔軟に変えていきます。

スプリントのイテレーション

自分たちのチームでは1週間のイテレーションと2週間のイテレーションを使い分けていました。

2週間スプリントはプロダクトオーナーと開発者の目線が揃ってエンジニアが着手するアイテムの内容に迷いがなく、調査と開発に集中できる中盤で実施しました。

1週間スプリントは作業を前に進めるより、コミュニケーション齟齬を防止するフェーズで実施していました。それは仕様があまり定まらない最初期と、考慮漏れを潰さなければならず細かいタスクばかりになりがちなリリース直前の時期です。このように変化が多く、不確実性が高い時期ほどフィードバックサイクルを短くすると良いと学びました。

この時はリファインメントとスプリントプランニングで半日ほどかかっていたため、2週間のイテレーションであれば実働は8営業日でした。

スプリントとスプリントレビューの予定を押さえる

スプリントの開始時点で、そのスプリントのレビュー会に参加して欲しい人の予定をカレンダーで押さえました。レビュー時にレビューをして欲しい人がいないという事態を避けるためです。

例えば水曜日にスプリントが始まる場合、2週間イテレーションなら翌々週の火曜日がスプリントレビューです。これを何スプリントか繰り返していくと、チーム外の人に火曜日はスプリントレビューがあるから予定を空けておこうと思ってもらうことができます。

良いスプリントはスプリントごとに不確実性が下がるもの

リリース日がいつかと聞かれても、開発当初は粗い見積りしか出せません。開発とリリース日の関係はアジャイルサムライの「荒ぶる四天王」の考え方を参考にしていました。

荒ぶる四天王とは、予算・品質・スコープ・期限です。これらのうち品質を下げることはできません。また予算が増えて新しい人がチームに入ったからといってリリースが早くなるという確証もありません（いわゆる「人月の神話」）。そして四半期決算と年度決算を区切りとするのがビジネスであるため、期限日は大きくずらせません。よって開発のスコープを調整することがベストなのです。

どの現場でも「最低限の機能をスピーディにリリースしよう」と号令がかかります。このときプロダクトオーナーと開発者にできるのはこの最低限、つまり開発スコープを調整することだけなのです。

残念なことに最低限の機能だけでリリース日の見積もりをしても、リリース予測日は往々にして遅れる方で外れます。最低限の機能に絞っても、開発を始めると想定外のことが発生するからです。そして、リリースを遅らせる想定外の出来事はあらかじめ予測はできず実際に経験しないとわからないのです。

そこでスクラム開発では、想定外の出来事が発生することを事前に考慮に入れます。何が想定外の足枷になるかはわからないけど、想定外の事態が発生しても適切に対処する方法を用意しているのです。それは想定外の出来事を見つけたら素早くチームに共有し、議論し、意思決定を行うという基本的なことです。この地道な活動を積み重ねることでプロジェクト全体の不確実性が減っていくのです。

スクラムでは開発全体において不測の事態があればスプリントで対応し、スプリント中に予想外のことがあればデイリースクラムで対応するのです。

スプリントを繰り返していくうちに開発は進みます。機能が揃い始めてユーザーのできることが着実に増えていきます。スプリントを経るごとに想定外の出来事が減ると同時に不確実性が減ります。するとリリース日の予測精度も上がります。2週間のイテレーションでスクラムを実施しているのであれば、あと2スプリントでストーリーポイントを全て消化できるというタイミングで予想したリリース日にほとんど誤差はなくなるのです。

開発を前に進めることで時間が経つにつれて不確実性が低減することは、一般的に不確実性コーンという図で説明されます。

（不確実性コーン）の画像

スプリントの実施は不確実性を減らすことに直結するのです。

次回はデイリースクラムとプロダクトインクリメントついて説明します。