スプリントプランニング：スプリントを乗り切るためのミーティングの進め方

天気予測が「午後3時に確実に雨が降る」と断言するのではなく、「70％の確率で雨が降る」と伝えるのには理由があります。予測では入手可能な情報を基に不確実性を考慮し、新しいデータが入るたびに更新されるからです。予測を確実な約束と誤解しない限り、その予測を参考に午後のプランを立てることは可能です。

スプリント計画も同様の原則に基づいて行われます。スクラムチームには、プロダクトバックログ、利用可能なキャパシティの見積もり、そして達成したい目標があります。しかし、作業の詳細の中には、スプリントが進むにつれて初めて明らかになるものもあります。1時間先まで綿密に計画を立ててしまうと、そうした発見のための余地がほとんど残されません。一方で、共通の方向性を持たずにスプリントに臨むと、何に注力すべきかを判断するのが難しくなります。

その目的は、価値ある成果について合意し、それを達成するためにチームがどれだけの仕事を完了できるかを予測することです。そこから、チームはスプリントの目標を見失うことなく、新たな知見を得ながらプランを適宜調整していくことができます。

このガイドでは、バックログの準備、時間配分のある計画アジェンダ、実用的なキャパシティの算出方法、そしてスプリント中にプランを調整する方法を示す例について解説します。

スプリントプランニングとは？

スプリントプランニングは、各スプリントの開始時に開催されるスクラムイベントであり、チームが何を達成したいか、そしてその仕事にどのように取り組むかについて合意を形成するためのものです。このイベントには、プロダクトオーナー、スクラムマスター、開発者を含むスクラムチーム全員が参加します。また、セキュリティエンジニアや顧客対応のリーダーなど、他の専門家も、その意見がチームの適切な意思決定に役立つ場合には参加することができます。

『スクラムガイド』によると、すべての計画セッションでは、3つの成果を生み出す必要があります。それは、作業の価値を説明するスプリント目標、その目標をサポートするプロダクトバックログアイテムの選択、そしてそれらをデリバリーするための初期プランです。これらを合わせてスプリントバックログを構成し、開発者はスプリントの進行に合わせてこれを継続的に更新していきます。

『スクラムガイド』では、1か月のスプリントの最大時間を8時間と定めており、スプリント期間が短い場合は通常、それより短い時間で済みます。バックログが十分に精査されていれば、以下のアジェンダは2時間で完了します。

これらの用語の一部に馴染みがない場合は、当社の用語集でアジャイルやスクラムの基礎を学んでください。

スプリント計画で答えられる3つの質問

すべてのスプリント計画セッションは、次の3つの質問を中心に進められます：

『スクラムガイド』では、提供したい価値を起点として、これらの質問を中心にプランを進めます。全員がそれを明確に理解すれば、どのバックログアイテムに注力すべきか、またチームが合理的に引き受けられる仕事量はどれくらいかを判断しやすくなります。

スプリントが重要な理由

スプリント目標は、チームが目指すべき方向性を示し、ステークホルダーが何を期待すべきかを理解するのに役立ちます。プランニングセッションが終了する前に、スクラムチームとこの目標について合意しておきましょう。

「34ストーリーポイントを完了する」といった作業量の目標ではなく、「試用版ユーザーがチームメイトを招待できる」など、誰もが認識できる成果を記述してください。予期せぬ問題が発生した場合、この目標があれば、チームは意図した成果を維持しつつ、どの作業を調整すべきかを判断するのに役立ちます。

チームがこのスプリントで完了できる作業

目標について合意したら、次はチームが現実的に何を成果として提供できるかを検討する段階です。

開発者は、利用可能なキャパシティ、過去のパフォーマンス、および「完了の定義（Definition of Done）」を考慮しつつ、プロダクトオーナーと協議してバックログ項目を選定します。また、このタイミングは、チームがスプリント作業に割ける時間に影響を与える可能性のある既存のコミットメントを見直すのにも適しています。

多くのチームでは、バックログアイテムの相対的な努力や複雑さを比較するためにストーリーポイントを使用しています。フィボナッチ・スケールは、特に必要な努力が不明確な場合、こうした議論を体系化するのに役立ちます。

チームがどのように仕事を進めるか

バックログアイテムが選択されると、開発者はそれらを「完了の定義（Definition of Done）」を満たす完成したプロダクトインクリメントに変える方法を検討します。『スクラムガイド』では、大きなアイテムを、多くの場合1日以内で完了できる規模の小さな作業単位に分割することを推奨しています。

とはいえ、sprintの1時間ごとに詳細なプランを立てる必要はありません。最初の数日間はより詳細なプランが必要かもしれませんが、後半のタスクについては、新たな詳細が明らかになるにつれて調整の余地を残しておくことができます。初期の見積もりを確固たる約束として扱うと、途中でスコープが変更された場合でも、チームは当初の数値を達成しなければならないというプレッシャーにさらされることになります。

Scrum.orgのCEOであるデイブ・ウェスト氏は次のように説明しています：

納期を守るために使われる予測は、見積もりに余裕を持たせたり、リスクを隠したり、数字を達成するために「完了」の定義を密かに変更したりするなど、信頼を損なうような行動をまさに招いてしまいます。

スプリント計画とバックログの精緻化の違いは何ですか？

バックログの精査を行うことで、チームは次のスプリントに何を含めるかを決定する前に、今後の仕事内容をより明確に把握できるようになります。スプリント計画では、その準備を基に、目標について合意し、バックログアイテムを選択し、初期のデリバリープランを策定します。

これら2つの活動は、スクラムにおいてそれぞれ異なる目的を果たします：

スプリントプランニングの際にチームが明確な選択を行えるよう、今後のバックログアイテムを十分に精査しておいてください。どの程度の準備が有効かは、優先度がどれほど急速に変化するか、またどれほどの不確実性が残っているかによって異なります。バックログの下位にあるアイテムについては、選択時期が近づくまで詳細度を低く保っても構いません。

スプリントプランニングの準備方法

数日前に、バックログの形が適切な状態にあること、そして全員が意思決定に必要な情報を手元に持っていることを確認しておきましょう。そうすれば、セッションでは、すべての要件をゼロから解決する必要なく、何を納品するか、そしてどのように取り組むかについて議論に時間を割くことができます。

次のスプリントの前に確認すべきチェックリストは以下の通りです：

スプリントのレトロスペクティブとプランニングセッションの日程を近接して設定する場合は、どちらのミーティングでも十分な議論ができるよう、十分な時間を確保してください。レトロスペクティブでの知見は次のスプリントのプランに反映されるべきものであるため、どちらのミーティングも慌ただしい印象を与えないようにしてください。

スプリント計画のアジェンダ：2週間のスプリントにおける時間配分例

2週間のsprintの場合、特にバックログがすでに精査済みの場合は、2時間のプランニングセッションから始めましょう。仕事に複雑な依存関係が含まれている場合や、議論を要する決定事項が複数ある場合は、余裕を持った時間を確保するようにしてください。

このサンプルアジェンダは、チームのニーズに合わせて調整可能です。

終了前に、「Fist of Five」のような簡単な確信度チェックを行うとよいでしょう。これは、全員がプランに対する確信度を0本から5本の指で評価するものです。もし誰かが低い評価をした場合は、その懸念の原因を尋ねてみてください。未解決の依存関係、過度に野心的な予測、あるいはさらなる議論が必要な要件などが明らかになる可能性があります。

その目的は、プランを調整する時間がまだあるうちに、懸念事項を洗い出すことにあります。

6つのステップでスプリントプランニングを実施する方法

バックログの準備が整い、参加者が確定したら、プランニングセッションを開始します。ここでの目標は、チームが優先度と利用可能なキャパシティを、確実に達成できると確信できるプランへと落とし込めるよう支援することです。

ステップ1：過去の仕事を振り返り、スプリント目標について合意する

まずは、何が完了し、何が未完了か、そしてレトロスペクティブで決定されたアクションが次のスプリントに影響を与えるかどうかを簡単に確認することから始めます。スプリントレビュー全体を振り返るのではなく、チームの優先度やアプローチを変える可能性のある点に焦点を当ててください。

次に、プロダクトオーナーに提案されたスプリント目標を紹介してもらい、それがより広範なプロダクト目標をどのようにサポートするかを説明してもらいます。開発者には、その範囲について質問したり、依存関係を指摘したり、調整案を提案したりする余地を与えてください。

例えば、目標が「顧客が営業担当に連絡することなくチェックアウトを完了できるようにすること」である場合、成功したチェックアウトとはどのような状態かを合意します。そこには、支払いの確認やエラー処理も含まれますか？ 最初のリリースにおいて、レシートを自動で送信することは必須ですか？

こうした議論を通じて、チームが目指すべき目標を明確に定義することができます。バックログアイテムの選択が進むにつれて表現は変化するかもしれませんが、プラン終了前には全員が最終目標について合意しておく必要があります。

ステップ2：チームの利用可能なキャパシティを算出する

仕事を選択する前に、開発者がスプリントに現実的にどれだけの時間を割けるかを明確にしておきましょう。

まず、稼働日数と各メンバーの予想される稼働時間を把握します。次に、予定されている休暇、スクラムイベント、サポート業務、その他の既知の予定を考慮に入れます。開発者が週の半分を本番環境の問題対応に費やしている場合、その時間はすでに割り当てられており、スプリントで計画された仕事には充てられません。

簡単な計算式は次の通りです：利用可能なキャパシティ ＝ 総労働時間 － 既定のコミットメント

例えば、2週間で80時間の仕事がある開発者の場合、休暇が8時間、ミーティングが10時間、サポート業務が12時間あるかもしれません。これにより、追加の不確実性を考慮する前の仕事時間は50時間となります。

この数値をチームの過去の実績と比較してください。ベロシティは、チームが過去のスプリントでどれだけの仕事を完了したかを示し、キャパシティは今回のスプリントで利用可能な時間を反映しています。

ステップ3：前回のスプリントで完了しなかった仕事を再評価する

未完了のバックログアイテムは、新しいスプリントに追加する前に、改めて見直す価値があります。2週間前には重要だったアイテムでも、優先度が変わっている可能性や、チームが残りの仕事量に影響を与えるような新たな知見を得ている可能性があります。

各アイテムをプロダクトオーナーと確認し、以下の点を検討してください：

スプリント内に残っている仕事については、残りの工数を基に、どれだけのキャパシティが必要になるかを判断します。半分まで完了したアイテムは、当初の見積もりよりも少ない工数で済む場合がありますが、「完了の定義」を満たすまでは未完了として扱われます。

ステップ4：目標達成につながるバックログアイテムを選択する

キャパシティと未完了の作業を把握した上で、開発者は自分たちが完了できると見込むプロダクトバックログアイテムを選択できます。

まず、スプリント目標を直接サポートするアイテムから取り上げましょう。それらの受け入れ基準、技術的な依存関係、およびデリバリーに影響を与える可能性のある不確実性について議論します。アイテムが大きすぎたり、不明確だったりする場合は、スプリント内で価値を提供できる小さな単位に分割することを検討してください。

メンテナンスやその他の製品の優先度に時間を割く余地があるかもしれませんが、その仕事を引き受けることで主要な目標が危険にさらされる可能性がないか確認してください。

どの程度のキャパシティを確保すべきでしょうか？

予期せぬサポート業務を定期的に処理するチームにとっては、利用可能なキャパシティの80％のみを計画対象とすることが妥当な出発点となり得ますが、スクラムでは固定の割合を規定しているわけではありません。

チームで頻繁に中断が発生している場合は、調整済みキャパシティの10～20％を予備として確保し、その余裕分を過去のスプリントで実際に必要だった量と比較してみてください。仕事が安定しており、中断が少ないチームであれば、必要な予備は少なくて済むでしょう。一方、インシデントが頻繁に発生する稼働中のサービスをサポートしているチームでは、より多くの予備が必要になる可能性があります。

同じコミットメントを二重にカウントしないようにしてください。ステップ2ですでに予定されたサポート時間が差し引かれている場合、追加のバッファは、その既知の作業負荷を超える不確実性をカバーするものです。算出されたキャパシティは、達成すべきターゲットではなく、議論の指針として活用してください。

ステップ5：仕事を細分化し、依存関係を確認する

バックログアイテムを選択したら、開発者はそれらをどのように成果物として提供するかについて検討します。これには、大規模なアイテムを開発、テスト、統合、レビューの各タスクに分割することが含まれます。

作業の順序を注意深く確認してください。チェックアウト画面が決済プロバイダーとの依存関係にある場合、チームはその依存関係がいつまでに整っている必要があるかを把握しておく必要があります。セキュリティ変更について他チームの承認が必要な場合は、その決定がどのように、いつ行われるかを明確にしておきましょう。

当面の仕事はより詳細にプランし、後のタスクについては今後の議論のために保留にしておきましょう。『スクラムガイド』では、選択されたアイテムを、通常は1日以内を目安とするより小さな作業アイテムに分解することを推奨していますが、作業の整理や配布の方法は開発者が決定します。

プランが「完了の定義（Definition of Done）」を反映しており、必須のテストや統合作業が含まれているか確認してください。依存関係によって納品が妨げられる可能性がある場合は、プランを確定する前に、選択したアイテムを見直すか、納品アプローチを調整してください。

ステップ6：スプリントバックログを確定し、共有する

スプリントの目標、選択されたプロダクトバックログアイテム、および初期のデリバリープランを、チームがアクセスして更新できる場所に記録してください。これらを組み合わせることで、チームが何を達成しようとしているのか、次にどの仕事に注力すべきかが明確になります。

ミーティングを締めくくる前に、目標について合意が得られていることを確認し、予測に関する懸念事項が残っている場合は、全員がそれを提起する機会を設けてください。重要な依存関係やキャパシティの問題が未解決の場合は、チームが作業を開始する前に、どのような変更が必要かについて話し合ってください。

スプリント期間中、デイリースクラムは開発者に、目標に向けた進捗を確認し、スプリントバックログを調整する機会を提供します。バーンダウンチャートやバーンアップチャートは進捗の変化を示すのに役立ち、その基盤となるタスクが詳細情報を提供します。新しい情報が選択されたスコープに影響を与える場合、開発者はスプリントの目標を危険にさらすことなく、プロダクトオーナーと調整について話し合うことができます。

スプリントプランニングの例：開発者6名からなるチーム

これらの決定が実際にどのように機能するのか見てみましょう。

B2Bの請求管理製品向けに、2週間のスプリントを計画していると想像してください。チームには6人の開発者がおり、提案されているスプリント目標は、「新規顧客が営業担当に連絡することなく、チェックアウト時にカード決済を行えるようにする」です。

バックログアイテムを選択する前に、チームがどれだけの時間を確保できるかを把握しておく必要があります。この例では、計画されたスクラムイベントやその他の業務を差し引く前に、各開発者が1日あたり6時間の集中的なプロジェクト仕事時間を確保できると仮定します。

10営業日におけるキャパシティ計算の仕組みは以下の通りです：

例として20%のバッファを設定した結果、計画された仕事に充てられる時間は216時間となりました。実際には、過去のスプリントで予期せぬ仕事がどれほど進行を妨げたかに基づいて、この余裕分を設定することになります。

スプリントの目標達成につながる仕事を選定する

キャパシティが確定したら、開発者はプロダクトオーナーと共に、チェックアウトに関連するバックログアイテムを確認します。

以下は、初期のタスクレベルの努力見積もりに基づいた、参考となる選択です：

これらの見積もりにより、計画作業枠内に6時間の余裕が生まれ、さらに予期せぬ仕事に備えて54時間のバッファが確保されています。また、プロダクトバックログにはレポート作成用ダッシュボードの改善項目も含まれています。これは価値のある仕事ですが、チェックアウトの目標には直接貢献しません。プロダクトオーナーと開発者は、これを将来のスプリントに持ち越すことで合意しました。

状況に変化があった場合は、プランを調整してください

6日目、支払いプロバイダーがAPIの変更を導入した結果、統合機能の一部が動作しなくなりました。開発チームは原因を調査し、必要な追加の仕事の見積もりを行います。

当初のタスク順序通りに進めるのではなく、プロダクトオーナーと影響について話し合います。修正が残りのキャパシティの範囲内であれば、それを優先し、オプションの受領書スタイル設定やその他の優先度の低いタスクを後回しにすることができます。支払い確認やその他の必須作業については、依然として「完了の定義（Definition of Done）」を満たす必要があります。

修正作業が予想以上に大規模になった場合、残りのスコープを見直し、sprint目標が依然として達成可能かどうかを再評価する必要があります。

チームが当初の予測よりも少ない数のバックログアイテムを完了して終了する場合もあります。しかし、顧客が意図した通りにチェックアウトを完了でき、その仕事が「完了の定義」を満たしていれば、スプリントの目標は達成されたことになります。

他のチーム向けのスプリント目標の例

スクラム自体は、明確な責任範囲やイベントが定義された特定のフレームワークですが、この計画アプローチはソフトウェア開発以外の仕事にも応用可能です。

例えば、マーケティングチームは「ウェビナーのランディングページを公開し、訪問者が手動のサポートなしに登録できるようにする」といった目標を設定するかもしれません。また、運用チームは「次回の入社予定者全員が、初日から必要な機器とシステムへのアクセス権を確保できるようにする」ことを目標に掲げることができます。

どちらの目標も、スプリントを通じてチームの意思決定を導くことができる成果を記述したものです。バックログアイテムやデリバリープランは異なる場合がありますが、チームは依然としてキャパシティを考慮し、成功したデリバリーとはどのようなものかについて合意する必要があります。

スプリント計画でよくあるミスとその解決策

チームがストーリーポイントを用いて個人のパフォーマンスを評価したり、不明確なバックログアイテムをミーティングに持ち込んだり、仕事の割り当てが硬直的すぎたり、テスト要件や外部依存関係を見落としたりすると、スプリント計画は問題に直面する可能性があります。

いくつかの調整を行うことで、これらの問題がデリバリーに影響を及ぼす前に発見できるようになります。

複数のスプリントにわたって同じ問題が繰り返し発生する場合は、それらをスプリントレトロスペクティブに取り上げ、次のスプリントでテストできる変更点について合意しましょう。これらのスプリントレトロスペクティブのテンプレートは、観察事項やフォローアップアクションを記録するのに役立ちます。

スプリントの終了時には、スプリントレビューミーティングを活用して、ステークホルダーと共に完了したインクリメントを検証し、チームが次に取り組むべき課題について話し合います。

ClickUpでスプリントプランニングを実施する方法

タスク、キャパシティの見積もり、計画上の決定事項がさまざまなツールに分散していると、スプリント計画にはより多くの努力がかかります。ClickUpはこれらの情報を一元管理するため、チームはキャパシティと併せて仕事を確認でき、プランが変更された際にも計画上の決定事項を見直すことができます。

まずは「ClickUp アジャイル・スプリント計画テンプレート」から始めましょう。このテンプレートのバックログ、開発ステータス、リソースの各ビューを活用すれば、今後の仕事を確認し、計画会議の準備を進めることができます。

無料テンプレートを入手する

重要な決定事項を順を追って進める方法は以下の通りです：

次回のプランニングセッションの前に、Brain²に「前回のスプリントプランニングセッションで、どのような未解決の依存関係が浮上しましたか？」と尋ねてみてください。Brainは、記録されたミーティングメモから背景情報を取得できます。それらの詳細を現在のタスクと照らし合わせて確認し、次の予測に反映させてください。

ClickUpの料金プラン

スプリント開始前に、どの程度までプランを立てるべきでしょうか？

スプリント計画セッションを終えた時点で、チームは仕事を開始するのに十分な明確さを得ているべきです。

上記の時間割付きアジェンダとキャパシティの例は、出発点となります。チームの作業量に合わせて調整し、予測と完了した作業、および中断事項を比較することで、次回のスプリントプランニングを改善しましょう。

ClickUpでは、プランに関するメモをスプリントタスクにリンクさせたり、仕事の内容の変更に応じてスプリントバックログを更新したりできます。チームは、調整すべき点を決定する際に、合意されたプランを参照することができます。

スプリント計画に関するよくある質問

スプリント計画とリリース計画の違いは何ですか？

スプリント計画では、チームが1つのスプリントの間に何を達成しようとしているか、そしてその仕事をどのように成果として届けるかに焦点を当てます。一方、リリース計画では、複数のスプリントにまたがってどの機能が利用可能になるか、ユーザーがいつそれらを受け取れるかなど、より長期的な視点で検討します。リリース予測は、チームが詳細を把握するにつれて変更される可能性がありますが、各スプリントの目標は、そのスプリント内の仕事を導く指針となります。

スプリント計画には「準備完了の定義（Definition of Ready）」が必要ですか？

いいえ。スクラムでは、正式な「準備完了の定義（Definition of Ready）」は必須ではありません。一部のチームでは、バックログアイテムの選択前に、明確な要件、管理可能なスコープ、既知の依存関係など、共有される期待値を設定するためにこれを活用しています。これらの基準は、議論を促進しつつ、必要に応じてチームがアイテムを精緻化することを妨げないよう、十分に軽量なものに保ってください。

スプリントプラン策定後にスプリントを中止することは可能ですか？

はい。スプリントを中止できるのはプロダクトオーナーのみであり、ビジネス上の優先度や市場条件が大幅に変化したなど、スプリントの目標が意味をなさなくなった場合に、中止という選択肢が検討されます。困難なタスクや不正確な見積もりだけでは、必ずしも中止の正当な理由にはなりません。

スプリントとアジャイルの違いは何ですか？

アジャイルとは、『アジャイルマニフェスト』の価値観と原則に基づいた、業務管理に対する広範なアプローチです。スプリントとは、スクラムフレームワークにおける1か月以下の固定期間のことで、その期間中、チームはスプリント目標の達成に向けて取り組み、実用可能なインクリメントを作成します。スプリントを使用せずにアジャイルの原則に従うことも可能です。例えば、カンバンは、固定期間の反復を必要とせずに、業務の継続的なフローをサポートします。

1つのスプリントに複数のスプリント目標を設定することは可能ですか？

スクラムでは、スプリントの目標を1つに定義し、それをスプリントの唯一の目的とします。その目標を危険にさらさない限り、他の優先度をサポートするバックログアイテムを選択することも可能です。チームが定期的に複数の関連性のない目標を必要とする場合は、その仕事がより広範な共通の成果を支えるものなのか、あるいは計画策定前に競合する優先度を解決する必要があるのかについて、話し合ってください。

スプリント計画会議では、バグをストーリーポイントで見積もるべきでしょうか？

スクラムにおいて、ストーリーポイントはオプションであり、バグについても同様です。バグの見積もりを行うチームは、いつ、なぜそれを行うかについて合意しておく必要があります。既知の不具合は計画段階で評価できますが、開発中に発見されたバグは、「完了の定義」を満たすためにすでに必要な仕事の範囲に含まれる場合があります。同じ努力を二重にカウントしないようにしてください。