スプリント計画

[アーティクル]
06/10/2015

Mitch Lacey 著。アジャイルとスクラムの導入と改善に特化したコンサルティング会社である Mitch Lacey & Associates, Inc の経営者です。

2012 年 1 月

スプリント計画は必ずしも難易度が高いとは限りません。この作業は時に楽しさを伴い、スクラムチーム全体にとって、どのようなことにコミットできるかを共に考える作業を通じて、仲間意識を生み出す時間となります。この記事では、スプリント計画を明確かつ有効なものにするために例と戦略を示し、チームがスプリントを計画する際に生じる共通の問題に対する潜在的な解決法について詳しく提供します。

対象

アプリケーションライフサイクル管理; Team Foundation Server

この記事の内容:

はじめに
予測とコミット
スプリント計画とは
実行する方法
一般的な問題
- シナリオ: 製品所有者が要求したすべてのストーリーには、チームがコミットできません。
- シナリオ: 製品所有者の準備が整っていません。
- シナリオ: 第 1 部の時間制限を超過します。
- シナリオ: 第 2 部の時間制限を超過します。
- シナリオ: 製品所有者が出席できません。
- シナリオ: 必要な受け入れ基準がチームにありません。
- シナリオ: 何をもって完了とするかを製品所有者が知りません。
- シナリオ: チームの見積もり/作業に対し、スクラムマスターまたは製品所有者が見積もりを行ったり、影響を及ぼしたりします。

計画は作成しません。スクラムします。実行あるのみです。

これをよく耳にします。スクラムおよびアジャイルは、計画なし、見積もりなし、ミーティングなし、何もなしの意味だと考えられています。これは実際からかけ離れています。アジャイルプロジェクトではさまざまなレベルで計画を作成します。毎日の計画や簡単なミーティング、週単位の計画 (スプリントまたはイテレーション、バックログ)、リリース計画 (プロダクトバックログ) などがあります。

スプリントの計画について説明します。

予測とコミット

2011 年夏、Ken Schwaber と Jeff Sutherland は共著『Scrum Guide』を改訂しました。この改訂では、スクラムで長い間認識されていた 1 つの行動が削除されました。それは、チームが製品所有者や顧客に対して行うコミットメントです。コミットメントは予測に置き換えられました。チームは作業にコミットするのではなく、作業を予測すると記述されています。

この論理は理解できますが、次の理由で、筆者は、コミットメントの方がより適していると考えます。

何かにコミットすることは、単に予測することとは異なり、チームの考え方に影響します。チームが予測する場合、できると言ったことを完全には達成できなくても容認されるという意味が含まれます。チームは予測からも学ぶことができるため、いずれは見積もりの差は縮小しますが、"予測" するチームは "コミット" するチームよりも差を縮小するために時間がかかります。
予測または見積もりは、プロダクトバックログに適しています。ただし、チームがプロダクトバックログのストーリーをスプリントバックログに移して分割するとき、さらに 1 段階精度を上げて詳細な内容を見つけ、それに自分たちがコミットできるかどうかを自らに問いかけることができます。予測においては、単なる予測だから、何かを見落としても後で考えればいいという安易な考え方にチームが流されるリスクがあります。

身近な例として、妻や夫またはパートナーに、"10 年は続くだろう"(予測) と言うのか、"すべてを捧げる"(コミット) と言うのかを想像してみてください。これならわかりやすいでしょう。

結局、スクラムは常識の問題です。コミットメントアプローチと予測アプローチの両方を試すことをお勧めします。これは単に使用する言葉の違いではないことは、経験によってわかります。賢明な開発者として、両方のアプローチを実験し、自分や自分のチーム、そして会社にとって最適な方法を使用してください。

スプリント計画とは

スプリント計画ミーティングを開いて、今度のスプリントでチームが "何を" 構築するか、そして "どのように" それを構築するかという計画を作成します。スプリント計画ミーティングと呼んでいますが、実際には 2 つのまったく異なる部分に分かれています。第 1 部では、チームが何を構築するように依頼されたかを話し合います。製品所有者とチームの両方が出席します。第 2 部では、必要な機能を構築するためにチームがどのように計画を立てるかを話し合います。第 2 部にはチーム全員が出席する必要がありますが、製品所有者の出席は任意です。なんらかの理由で第 2 部に出席しない場合も、製品所有者は質問に対応する必要があります。

スプリント計画ミーティングの第 1 部で、製品所有者は必要な一連のストーリーについてチームに説明します。これはストーリーの "何を" の部分に関するブレーンストーミングセッションです。製品所有者は、ストーリーを提示して、それぞれの要素がどのように相互作用するかを示し、インターフェイスについて順を追って説明します。さらに、インフラストラクチャまたはアーキテクチャの項目を確認できます。この目的は、それぞれのチームメンバーに十分な情報を伝達し、メンバーが機能の構築方法を検討できるようにすることです。チームは、次のようなさまざまな質問によって、"どのように" に関するミーティングに備えて情報を収集します。

"これらのストーリーすべての受け入れ基準は何ですか。"
"どのようなデータソースを使用しますか。"
"このコンポーネントのインターフェイスはどのような外観にしますか。"

スプリント計画ミーティングの第 2 部では、スプリントバックログの構築にチームの注意が向けられます。スプリントバックログとは、ストーリーとそれらをそのスプリント期間中に完了するために必要なタスクの一覧です。バックログを構築するために、チームは、製品所有者から要求された各ストーリーをタスクレベルに分割し、各タスクを 1 時間単位で見積もります。チームは、第 2 部が終了するまでに、スプリント期間中の完了をコミットするストーリーを決定します。

第 1 部と第 2 部を合わせたスプリント計画ミーティングは 2 ～ 8 時間かかります。一般的な経験則として、スプリント期間の 1 週間ごとに各部に 1 時間を用意するとよいでしょう。つまり、1 週間のスプリントを実行する場合、ミーティングは合計 2 時間になります (第 1 部に 1 時間、第 2 部に 1 時間)。一方で、4 週間のスプリントを実行する場合、ミーティングには合計 8 時間かかります (第 1 部に 4 時間、第 2 部に 4 時間)。

実行する方法

スプリント計画ミーティングでチームがストーリーの一覧を完了することにコミットすれば、スプリント計画の目的は達成されたことになります。ただし、各チームメンバーがそのコミットしやすいチーム体制を作るには、事前の計画と支援が多少必要です。

スプリント計画中、製品所有者には 1 つの仕事があります。ミーティングに出席して、必要な一連のストーリーについて説明することです。チームの目的は、製品所有者の観点からストーリーを理解して、製品所有者のビジョンを共有することです。スクラムマスターは、チームが十分に質問し、すべての結果データ (受け入れ基準、スケッチ、すべての前提) を把握するように徹底する必要があります。また、スクラムマスターは、チームが質問をタスクに分割し始めた後も、新たな質問が発生した場合は、そのことを製品所有者に知らせる必要があります。製品所有者が提示するストーリーのポイント合計はチームの履歴ベロシティにほぼ相当しますが、該当するスプリントですべてのストーリーを実行するかどうかは、スプリント計画ミーティングの第 1 部と第 2 部で話し合った内容に基づいて、チームが最終的に決定します。

チームは、製品所有者からすべての情報を取得した後、ストーリーをタスクに分割し、スプリントバックログを作成します。これにより、特定のスプリントのすべてのストーリー、メモ、受け入れ基準、タスク、見積もりを把握します。このための方法は多数ありますが、次の方法を使用すると、チームメンバー全員のアイデアを活用し、全員の意見を参考にしてタスクを分解できます。

スクラムマスターつまりミーティングの進行役がストーリーを読み上げて、全員が理解したかどうかをたずねます。製品所有者が説明したばかりなので、チームは理解しているはずです。チームに理解していないメンバーがいる場合は、再びストーリーを説明し、必要に応じて製品所有者に質問します。
次に、各チームメンバーに付箋を配ります。各チームメンバーに 1 枚の付箋に 1 人 1 つずつタスクを書いてテーブルの中央に出すように頼みます。
- メンバーは、付箋をテーブルの中央に出すときに、そのタスクを発表します。つまり、"ストアドプロシージャの更新" と書いてある場合には、それを口頭で発表します。このことは、着想を促し、"そうだ、データソースも更新する必要がある。" などと他のメンバーが発言するきっかけとなるため、重要となります。このときは、いずれかのメンバーが付箋に "データソースの更新" と書いて読み上げ、中央に出します。このブレーンストーミングアクティビティは、関連するすべてのタスクを洗い出すのに特に効果的です。この時点では重複は気にかけないようにします。すべてのタスクの付箋が出るまでに、通常、ストーリーごとに約 5 ～ 10 分かかります。
付箋がすべてテーブルに出されたら、次は整理します。すべてを壁に貼り付け、離れて見ると、たくさんの付箋があります。まず、重複しているものを探します。重複と思われる付箋を重ねてください。次に、似ているものや互いに依存するものなど、同時に処理するタスクを探します。たとえば、2 枚の付箋に類似した関係がある場合は、次の図のように少しずらして重ねます。

2 つのタスクが緊密に関連しており、ほぼ同一である場合は、次に示すようにほとんど重なるように貼ります。

チームは、付箋を並べ替えることで、タスクの一覧を選り分けて、残ったタスクの関係を視覚化できます。
タスクを並べ替えたら、次は見積もりを行います。タスクの見積もりではプランニングポーカーテクニックを使用します。カードの数字が点数ではなく時間であることだけが違います。このようにするのは、特に大きいタスクの場合に、時間に関して不必要な詳細に過度にとらわれる傾向があるためです。この恐れには正当な理由があります。会社がチームに対するムチとして見積もりを使用するケースが多すぎるためです。 "8 時間でできると言ったのに 12 時間もかかったじゃないか。どうしたんだ" または "8 時間かかると言ったのにかかったのは 4 時間じゃないか。見積もりを水増ししたのではないか。" と責めるわけです。

カードがストーリーポイントの見積もりの抽象性を維持するのに役立つのと同様に、タスクの見積もりにカードを使用すると、チームは、固定された一連の数字の中から選択する自由があると同時に、最終的には選択を強制されます。また、あるタスクの見積もりを 6 時間、6.5 時間、または 7 時間のどれにするかという議論が過熱することもなくなります。

最終的な見積もりがどのようなものでも、見積もりはチームが作成するものであり、チームの自信の強化、および製品所有者が依頼する作業をチームが完了できるかどうかに関して、ベロシティに基づく判断を支援することのみを目的とします。タスクの見積もりはメトリックではないため、そのようには使用しないでください。チームに対する武器として見積もりを使用しないでください。
タスクの見積もりが終了したところで、チームは、追加作業を引き受けるキャパシティがあるかどうかを判断する必要があります。そのためには、チームのキャパシティ、つまりスプリント期間中にチームが提供できる時間の合計を知る必要があります。キャパシティの判断は、全員が専任のチームであれば簡単ですが、複数のプロジェクトを掛け持ちするメンバーで構成されるチームの場合は少し難しくなります。各メンバーに、1 日あたりに (またはスプリント全体で) プロジェクトの作業にかけられる時間を記入するように依頼します。すべての数を合計すると、チームで使用できる合計時間数になります。たとえば、チームのキャパシティが 200 時間と判明したとします。 1 つのストーリーのタスクの合計に 30 時間かかると見積もられていた場合、もっと作業できるかとチームにたずねます。この初期の段階では、回答は明らかに "はい" です。

キャパシティにゆとりがあるため、次のストーリーに進み、1 ～ 5 のステップを繰り返します。

(Team Foundation Server を使用してこのタスクを達成する方法の詳細については、「共同作業 [リダイレクト]」を参照してください。)

ある時点で、もっと作業できるかという質問に答えるのが難しくなります。チームのキャパシティの限界に近づいているためです。このプロセスを進めるとき、スプリントはキャパシティの限界まで設定しないことをお勧めします。コップの縁まで水を入れると溢れやすくなります。これは、スプリントの場合も同様です。確保した時間を見積もり済みの時間で使い果たすと、スプリントの後半で新たなタスクが見つかった場合に溢れが発生します。緊急のタスク用に余地を残す必要があります。

スプリントのコミットメントを検討するとき、以前のスプリントのデータについて振り返って考察すると役立ちます。チームがいつも追加の作業を引き受ける必要が生じていませんか。その場合、チームは、スプリント計画中により多くの作業にコミットできた可能性があります。チームがスプリントで一部の作業を完了できないということが常態化していませんか。その場合、スプリントを完了できない根本原因に対処するまでは、チームはコミットメントに関してもっと慎重になる必要があるでしょう。

"グラスをどの程度満杯にするか" という質問に数値で答える方法の 1 つは、計画サイズの拡大を考慮することです。計画サイズの拡大は、実際にかかった時間と当初の見積もりを比較して計測します。たとえば、チームで提供するキャパシティが 200 時間であるとします。チームは、見積もりに基づいて 190 時間分の作業にコミットします。スプリントの終了時に、チームは、ストーリーには実際に 240 時間分の作業が含まれていたと計算します。つまり、計画サイズの拡大は 20% です。

このような差異があるチームは、振り返って調査するときに、時間を割いて次のような原因を考察する必要があります。

計画中に特定されずに実行中に見つかったタスクが多すぎないか。
チームが現在のスキルに基づいてタスクを過小評価していないか。
チームがキャパシティを過大評価していないか。
その他。

チームは、次のスプリント計画ミーティングで、ストーリーにコミットできるかどうかを決定するときに計画サイズの拡大も考慮する必要があります。例に戻ると、チームが引き続きキャパシティを 200 時間と見積もる場合は、履歴データから想定される計画サイズ拡大に対応するために全体の 20% を差し引く必要があります。つまり、少なくともこのスプリントでは、溢れを回避するために、160 時間に達したときにキャパシティの限界であると宣言する必要があります。

計画サイズの拡大を考慮することは、スプリントをどの程度満杯にするかを数値化する 1 つの方法です。ただし、キャパシティと厳密に一致させることが目的ではないことを理解してください。むしろ、目的は、適切な数、つまり、過度な負担なくチームの活動を促進する数のストーリーにコミットできるという自信をチームに持たせることにあります。他のすべての要因に変化がない場合、計画サイズの拡大は、次のスプリントをどの程度満杯にするかを大まかに決定する基準になります。

すべてのストーリーの見積もりが終了した時点で、つまりすべての時間がストーリーに割り当てられたら、製品所有者のところへ戻り、チームが実現にコミットしたスプリントバックログを共有します。スプリントは間もなく開始します。仕事に取りかかりましょう。

一般的な問題

スクラムを採用するチームを支援してコンサルティングを行ってきましたが、スプリント計画の成功を妨げる、同じ問題が何度も発生しました。スプリント計画は単純に見えますが、スクラムを始めたばかりのチームは苦労する傾向があります。このセクションでは、このような問題の多くとその潜在的な解決法について詳しく説明します。

シナリオ: 製品所有者が要求したすべてのストーリーには、チームがコミットできません。

時にはこのようなことがあることを想定する必要があります。このトピックの前半のステップ 4 ～ 5 のデータを使用してチームがコミットメントを裏付けできる限り、製品所有者は納得するはずです。余裕を見込みすぎたことやタスクが大きいことが、コミットできない原因にならないように、注意してください。スクラムマスターは、慎重すぎると考えられる見積もりについて注意を促し、それが正確かどうかを確認する必要があります。製品所有者は、見積もり時間が 2 桁のタスクについて質問する必要があります。作業日数が 2 日を超えると見積もられたすべてのタスクは、より小さいタスクに分割し、再見積もりする必要があります。このことはすべてのプロジェクトに当てはまりますが、1 週間または 2 週間のスプリントを実行しているチームでは特に困難です。

シナリオ: 製品所有者の準備が整っていません。

スクラムの価値基準の 1 つは敬意です。準備せずにミーティングに出席することは敬意を欠いています。製品所有者が出席しても、チームが必要とする情報がなければ、チームはどうすればよいのでしょうか。製品所有者の準備が整うまでミーティングを延期するという選択肢もありますが、これは同じ行為を助長するだけなのでお勧めしません。もう 1 つの方法はスプリントを取り消すことです。これは有効ですが極端です。

最適な解決法には 2 つの面があります。まず、プロダクトバックログがなんらかの優先順位に基づいて並べられている必要があります。製品所有者が具体的な一連のストーリーを用意していない場合でも、キャパシティの限界まで、またはキャパシティを超えるまで、チームと製品所有者が優先順位に基づいてストーリーを議論することだけはできます。これにより、チームは、ミーティングの第 2 部で厳密なコミットメントを通常どおり決定できます。

ミーティング後、スクラムマスターは、製品所有者がなぜ準備していなかったかを把握するように努める必要があります。問題が責任感の低さだった場合、スクラムマスターは、一連のストーリーを準備してミーティングに出席することの重要性を製品所有者に説明します。一方、製品所有者が準備できなかった原因として、チームがグルーミングを支援できなかったことが考えられる場合、スクラムマスターはそれらの問題も解決するように手助けする必要があります。

シナリオ: 第 1 部の時間制限を超過します。

もう 1 つの価値基準はフォーカスです。ミーティングの第 1 部が長引く場合、これはフォーカスが欠けていることを示しています。準備や優先順位付けが不足していたり、説明しようとするストーリーが多すぎたりするために、製品所有者がフォーカスを失うことがあります。または、チームの "何を" の議論が "どのように" の具体例に脱線したために、フォーカスが失われることもあります。

スクラムマスターは、議論を進行させるために、製品所有者に対しては十分に説明できないストーリーを棚上げするように要求し、チームに対しては第 1 部では詳細な実装の議論を避けるように要求する必要があります。フォーカスが失われた議論の単純な解決策としては、ストップウォッチやタイマーを使用することです。

シナリオ: 第 2 部の時間制限を超過します。

これもフォーカスに関連します。話が止まらないチームの場合、ミーティングの進行を制御するために必要なのは、議論を制限するルールの設定だけです。ゆでたまご用タイマーを持ち込んで、タスク見積もりの議論にかける時間を 1 タスクあたり 1 分または 2 分に制限します。できるだけ正確にしますが、100% の精度は不要です。

または、第 2 部でのフォーカスの欠如は、スプリント実行におけるプロダクトバックログのグルーミング不足の前兆になります。グルーミングは、チームが将来のストーリーを確認し、設計の方向性を明確にしたり、アーキテクチャに関する質問に対処したりするために、製品所有者と協力してストーリーまたはスパイクを追加するための時間です。プロダクトバックログを定期的にグルーミングしていないと、スプリントバックログの計画は複雑で苦痛を伴う作業になります。

シナリオ: 製品所有者が出席できません。

製品所有者がなんらかの理由でミーティングに出席できず、代理人も指名しなかった場合は、製品所有者が準備しないでミーティングに出席した場合と同様に対処します。上位の項目について検討し、できるだけそれらにコミットします。製品所有者のスケジュールに合わせてミーティング時間を変更しようかと考えることがあるでしょう。それはしないでください。ミーティング時間の変更は、多数を犠牲にして 1 人のニーズに合わせることです。その価値はありません。

シナリオ: 必要な受け入れ基準がチームにありません。

第 1 部では、"この受け入れ基準は何ですか" または "作業が受け入れられるには、何をする必要がありますか" のように製品所有者に質問することをチームに勧めています。この作業が欠けると、第 2 部でタスクを決定するときに、ストーリーを終了させる方法がわからなくなります。チームが第 1 部で聞いた内容に基づいて推測するしかない場合、スプリント終了時に製品所有者がストーリーが完了していないと判断するリスクが発生します。最初から各ストーリーについて受け入れ基準を確認します。スクラムマスターは、製品所有者がこのデータを提供するように指導してください。

シナリオ: 何をもって完了とするかを製品所有者が知りません。

チームが受け入れ基準を必要とするのと同じく、製品所有者は、チームが言う "ストーリー完了" という言葉の意味について最新説明を必要としています。この完了リストを目立つように貼り出して、最新の情報を製品所有者に常に提供する必要があります。完了リストが古い状態であると、何が完了したのかという共通理解が失われて計画が困難になります。スプリントのレビューや振り返りにおいては、常に完了リストを更新するようにしてください。

シナリオ: チームの見積もり/作業に対し、スクラムマスターまたは製品所有者が見積もりを行ったり、影響を及ぼしたりします。

製品所有者はミーティングの第 2 部にも出席できますが、第 2 部での製品所有者の役割は要件の明確化や特定の質問の対応に限られます。製品所有者は、ストーリーの実装方法に関するチームの議論に干渉することはできません。タスクの見積もりについても発言権はありません。製品所有者は、チームの作業を信頼する必要があります。

製品所有者がこのようなガイドラインから外れて行動する場合、スクラムマスターは製品所有者が適切な役割を果たすように指導する必要があります。製品所有者が受動的な役割の受け入れを拒否した場合、スクラムマスターには製品所有者の退出を求める権限があります。

スプリント計画は必ずしも難易度が高いとは限りません。この作業は時に楽しさを伴い、スクラムチーム全体にとって、どのようなことにコミットできるかを共に考える作業を通じて、仲間意識を生み出す時間となります。ミーティングが長引いている場合は、そのことが根本原因である問題によって引き起こされていないかどうか考えてください。スクラムマスターとしては、製品所有者とチームが確実にプロダクトバックログをグルーミングするようにして、ミーティングのフォーカスが失われないようにします。また、ミーティングの前に、製品所有者がストーリーの受け入れ基準を準備し、万全の状態で出席するように支援します。さらに、製品所有者とチームが目の前のタスク (スプリントで何にコミットできるかを決めること) に集中できるようにします。