スプリント計画

[アーティクル]
02/21/2013

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

2012 年 1 月

スプリント計画は必ずしも難易度が高いとは限りません。これは、楽しいことも多く、「何にコミットできるか」という質問に答えようとして共同作業することで、スクラムチーム全体が仲間意識を育む時間です。この記事では、スプリント計画を明確かつ有効なものにするために例と戦略を示し、チームがスプリントを計画する際に生じる共通の問題に対して詳しいソリューション候補を提供します。

対象

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

この記事の内容:

Introduction
予測とコミット
スプリント計画とは
実現する方法
一般的な問題
- シナリオ: チームが、製品の所有者が要求したすべてのストーリーにコミットできません。
- シナリオ: 製品の所有者が準備していません。
- シナリオ: 第 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 つのタスクを書いてテーブルの中央に出すように、各チームメンバーに頼みます。
- メンバーは付箋をテーブルの中央に出すときに、そのタスクを発表します。つまり、"ストアドプロシージャの更新" と書いてある場合には、それを口頭で発表します。これが重要です。アイディアを刺激して、他のメンバーが「そうだ。データソースも更新する必要がある」と言い出すからです。そこで、いずれかのメンバーが付箋に "データソースの更新" と書いて読み上げ、中央に出します。このブレーンストーミングアクティビティは特に効果的で、関連するすべてのタスクが湧き出します。この時点では重複については考慮しないでください。すべてのタスクの付箋を出すまでに、通常、ストーリーごとに約 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 つの方法ですが、これは同じ行為を助長するだけなのでお勧めしません。もう 1 つの方法はスプリントを取り消すことです。これは役立ちますが極端です。

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

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

シナリオ: 第 1 部がタイムボックスを超過します。

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

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

シナリオ: 第 2 部がタイムボックスを超過します。

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

または、第 2 部でのフォーカスの欠如は、スプリント実行におけるプロダクトバックログの手入れ不足の前兆になります。手入れでは、チームが将来のストーリーを確認し、設計の方向性を明確にしたり、アーキテクチャに関する質問に対処したりするために、製品の所有者と共に作業してストーリーまたはスパイクを追加できます。プロダクトバックログに通常の手入れが行われていないと、スプリントバックログの計画は扱いにくくて骨の折れる作業になります。

シナリオ: 製品の所有者がいません。

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

シナリオ: 必要な受け入れ基準をチームが認識していません。

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

シナリオ: 製品の所有者が完了の意味を知りません。

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

シナリオ: スクラムマスターまたは製品の所有者が作業を見積もります (または、チームの作業見積もりに影響を与えます)。

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

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

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