スプリント計画：アジャイルのベスト実践

計画の基礎

質の高いスプリント計画には、筋道の立った進め方が必要です。過去のスプリントを分析し、チームがどれだけの作業をこなせるかを見極め、目標をはっきり定めます。詳しくはこちら：ITチーム向けのITプロジェクト管理ソフトウェア。

1. 計画の準備は十分に前もって始める必要があります。Product Ownerは、会議の少なくとも1日前までにbacklogを整え、優先順位を付けておきます。開発チームには、user storyを事前に読み、不明点を質問できる機会が必要です。
2. 古典的な割り当てルール:スプリントの各週につき計画に2時間。2週間のスプリントなら4時間です。ただし、この時間を1回の長い会議にまとめるより、短いセッションに何回か分けたほうがうまくいくことがよくあります。

準備段階

質の高い準備がなければ、スプリント計画は良くなりません。この段階は軽く見られがちです。それでも、プロセス全体の成否はここで決まります。

• Definition of Ready (DoR)は、user storyをスプリントに入れる前に満たすべき準備完了の基準を定めます。各ストーリーには、明確な受け入れ基準、複雑さの見積もり、他のタスクとの依存関係がそろっている必要があります。DoRが守られないと計画は混乱し、チームは実行の計画を立てる代わりに、内容の確認に時間を取られてしまいます。
• Backlog refinementは、スプリント計画の直前にだけ行うものとは違い、定期的に行うべきものです。このプロセスにスプリント時間の10%を充てるのが標準的なやり方です。チームは週に何度か短いリファインメントセッションを開き、今後のスプリントに向けてストーリーを少しずつ仕上げていけます。
• Velocity分析は、チームが実際にどれだけ届けられるかを正確に示してくれます。直近3〜5スプリントの平均Velocityに加えて、次のスプリントの生産性を左右しそうな要因も考える必要があります。予定された休暇、祝日、たまった技術的負債、外部との依存関係などです。

計画セッション

スプリント計画は2つの段階に分かれます。まず、スプリントで何を届けるかを決めます。次に、選んだ作業をどう実装するかを決めます。二つの段階では必要な入力も、生まれる出力も異なります。混ぜてしまうと、どちらの効果も落ちます。

1. チームはProduct Ownerと一緒に、選んだすべてのuser storyをまとめるスプリント目標を定めます。目標は具体的で測定でき、参加者全員にとって意味のあるものにします。効果のない目標:「ユーザーエクスペリエンスを向上させる」。効果的な目標:「ユーザーはワンクリックでソーシャルメディア経由で登録できるようになる」。
2. 開発チームは選んだストーリーをタスクに分け、時間単位で見積もります。この作業で、ストーリー単位では見えなかった複雑さや依存関係が表に出てきます。各タスクは8時間以内に収めます。これを超えるタスクは、さらにサブタスクに分けます。

役割と責任

スプリント計画がうまくいくかどうかは、参加者一人ひとりが自分の役割を理解し、その範囲で動けるかにかかっています。

• Scrum Masterはプロセスを進行し、タイムボックスを守らせ、チームが結論を出せるよう手助けします。解決策を押し付けることはしません。的確な質問を投げかけ、議論が脇道にそれないようにします。
• Product Ownerはbacklogの優先順位付けと、どの機能を先に実装するかの判断に責任を持ちます。各ストーリーのビジネス価値を説明でき、開発チームが見積もれるだけの具体性で質問に答えられるよう準備しておく必要があります。
• 開発チームは成果を届けることにコミットします。このコミットメントは外から割り当てられるものであってはならず、チーム自身から生まれる必要があります。チームが自分で決めた約束は、押し付けられた目標とは質の違うモチベーションと責任感を生みます。

よくある間違い

• 能力の過大評価は、最も頻繁なスプリント計画の誤りです。チームは、特にプロジェクトの初期や、うまくいったスプリントの直後に、こなせる以上の作業を引き受けがちです。原則は、控えめに約束して多めに届けることです。守れなかったコミットメントは利害関係者の信頼を損ない、その後のスプリントでもチームのやる気を下げます。
• 時間バッファーの欠如は重要な構造的誤りです。スプリント計画には、予期しないタスク、バグ、技術サポートの依頼に備えて10〜20%のバッファ時間を入れておくべきです。この予備を最初から追加のストーリーで埋めてはいけません。どのスプリントにも必ず発生する計画外の作業を吸収するための時間です。
• 依存関係を無視するとスプリントの途中でブロッカーが生じます。外部との依存関係は、すべて計画の段階で洗い出して解消しておく必要があります。タスクが他のチームや外部ベンダーに依存している場合は、期限を事前にすり合わせ、スプリント開始前に確認を取っておきます。

プロセス監視

成熟したAgileの実践では、計画プロセスそのものも継続的に改善していきます。レトロスペクティブでは、スプリントの実行結果に加えて、計画の質も独立した入力要素として分析する必要があります。

分析のためのメトリクス:

• 見積もりの精度 — 各ストーリーとタスクの計画時間と実際の時間の比較
• 完了したストーリーの割合 — スプリントでコミットしたストーリーのうち、終了までに届けられたものの割合
• 計画後のスプリントの変更回数 — 計画がどれだけ安定しているか、要件がどれだけ明確かを示す指標
• 計画に費やされた時間 — 標準の割り当てと比べ、慢性的なかけすぎやかけなさすぎを見つけるために記録します

Burndownチャートはスプリント全体の進み具合を追い、手を打てるうちに問題を浮かび上がらせます。予定した作業が終わらないとチャートが示したら、対応が必要です。残りのタスクの優先順位を付け直すか、優先度の最も低いuser storyをスプリントの範囲から外します。

計画の適応

• リモートチームはスプリント計画に特定の適応を必要とします。専用のコラボレーションツールをそろえ、リモートの参加者全員が平等に発言できるよう積極的に場を回す必要があります。分散チームでは、1回の長い会議より短いセッションを何回か開くほうが、参加意識もアウトプットの質も高くなる傾向があります。
• 複数のチームを持つ大規模なプログラムはプログラムレベルでの調整を必要とします。Scrum of ScrumsやSAFe(Scaled Agile Framework)は、依存関係を共有するチームの間でスプリント計画をそろえるための仕組みを提供します。
• 保守プロジェクトは、スプリントの時間の多くがサポートやバグ対応に費やされるため、計画外の作業に充てる容量をはっきり確保しておく必要があります。スプリント容量の30〜50%をサポート作業に割り当て、残りを新機能の開発に回すのが標準的な配分です。サポートをおまけの負担として扱わず、計画に組み込んだ容量として扱うことで、納期の遅れを防げます。

関連記事:

プロジェクト管理のフレームワークと制約のバランスについては、プロジェクト管理の三角形:スコープ、時間、コストのバランスをお読みください。

Kanbanボードと視覚的なワークフロー管理の実用的な概要については、Kanbanボードとは何か?視覚的なワークフロー管理のガイドをお読みください。

Agileチームがペルソナを使って実際のユーザーニーズからずれないようにする方法については、Agileペルソナ:Agileプロジェクトにおけるユーザー中心の開発の強化をお読みください。関連情報：カンバンボード。

結論

効果的なスプリント計画には、筋道の立った進め方と継続的な改善が必要です。改善はプロジェクトが終わってから行うものとは違い、日頃から意識して続けるものです。レトロスペクティブは、そのための仕組みです。スプリントの実行結果と、その結果を形づくった計画の内容をあわせて分析できます。こうして計画プロセスそのものが、Agileが製品開発に用いるのと同じ反復的な改善の対象になります。