スプリント プランニング ミーティングとは
ソフトウェア開発チームは、イテレーションと呼ばれる新しいソフトウェア バージョンの展開を順調に進めるために、スプリントに依存します。イテレーションに含める作業は需要が競合するため、開発チームはスプリント中に何に焦点を当てるべきかを非常に明確にする必要があります。たとえば、特定のバグ修正が新機能の展開よりも優先されるか、またはその逆かを判断する必要があります。
この焦点を当てたアプローチで効果、生産性、品質を高めることができるため、アジャイルは他の分野や業界でも人気を集めています。
スプリントを開始する前に、プロジェクト チームはスプリント プランニング セッションに参加します。このセッションでは、次の 2 つの重要なことを決定します。
-
スプリント目標: スプリント中に提供できる成果を指します。
-
スプリント バックログ: その目標を達成するためにスプリント中に完了するタスクのリストです。
スプリント プランニングは時間が限定された活動で、通常は約 8 週間にわたって週に 1 時間行われます。
Agile Project Management E-book
How can Agile PM help you do more with less?
Agile project management empowers teams to adapt to change with increased speed and flexibility. Learn how to implement Agile PM and get the most out of the methodology.
スプリント プランニングはスクラムやその他のアジャイル手法に適している
スプリント プランニングは、応答性、柔軟性、継続的改善を優先するアジャイル開発手法の世界で重要な役割を果たし、優先度と市場が急速に変化している世界で組織が優れた方法で作業を管理することを支援します。顧客の要件や競争が厳しくなる中で、スプリント プランニングによって次に取り組むべき作業を決定します。
ソフトウェアでは、スプリント プランニングによって、デリバリできる製品の変更や機能、次のイテレーションで最も効率的にそれを展開する方法が決定されます。このプランニング プロセスにより、チームは現実的な量の作業に取り組み、最も重要な作業を最初に達成できます。結局のところ、品質を損なうことなくスプリント中に達成できることは限られています。
スプリント プランニングは、スクラムバンなどのハイブリッド アジャイルの手法にも使用されます。これは、スクラムと、トヨタに由来する視覚的な、プル指向の作業システムであるカンバンの混成語です。スクラムバンは固定された長さのイテレーションと標準化された引き継ぎプロセスを組み合わせたもので、複数の専門チームが 1 つの作業項目に取り組むことができます。
スプリント プランニングがスクラムでどのように機能するかを理解するには、まずこの手法の 主要な役割とプロセス を確認してください。スプリント プラニング中、プロジェクト チームはプロダクト オーナー (企業や組織のプロダクトに関係する主要な関係者) と協力し、スクラム マスター (チームをコーチングし、全員がミッションを伝達および理解できるようにすることでプロセスが順調に進んでいることを確認し、サーバントリーダーとしての役割を果たす個人) によってリードされます。
これらの参加者は、スプリントの終了時に開発および開始される製品バックログから引き出された機能や変更のリストであるスプリント バックログを作成します。スプリント バックログは、スプリント目標に応じて形成されます。つまり、スプリント中にデリバリが可能です。
“The most common mistake I’ve seen is when a team tries to plan a sprint when the product backlog is not ready with good user stories that are immediately actionable,” says Scrum Master Scott Luse of Dassault Systèmes and other companies. “Another, less common, mistake is to conduct a sprint planning meeting without having the product owner in the room to discuss the work and sprint goals. In both cases, the sprint will typically start with a low chance of success. A good Scrum master should protect the team and ensure this doesn’t happen” he adds.
Scrum and Agile expert Laura Neves, Program Manager at Microsoft, urges teams to make sure at the start that everyone is on the same page in terms of language and terminology.
「非常にシンプルながら便利な習慣は、スプリント目標、ロードマップ、完了の定義を記述する際に頭字語を使わないことです。チームに新人がいる場合は特に、誰もがそれらを正確に理解できるとは想定しないでください。それによって多くの説明や修正作業を避けることができます。また、頭字語を明記するということは、長く使用されている概念を新たに確認し直す必要があることを意味します。あなたやあなたのチームは、E2E フローの開始から終了までに起こることを本当に覚えていますか？」と問いかけています。
よりアジャイルなアプローチでプロジェクトを管理する必要がありますか？
アジャイル プロジェクト管理について知っておくべきことと、Agile PM のベスト プラクティスの導入を開始するのに役立つヒントをすべて学びましょう。
スプリント プランニング ミーティングの期間
スクラムのエキスパートは一般的に、スプリントの期間に毎週約 1 時間、最大で合計 8 時間をスプリント プラニングに費やすことを推奨しています。非常に複雑なプロジェクトでは、より多くの時間が必要な場合があります。また、スクラム チームの成熟度によっては、約 2 倍の時間がかかる場合があります。
チームが共に作業をしてきた時間がスプリントの長さを決定する上で非常に重要な要因となる理由を知るために、グループ開発が一定の段階を経て進むという考えを 1965 年に示した心理学者のブルース・タックマン (Bruce Tuckman) の研究を見てみましょう。
-
形成期: 新しいチームが結成されたり、新しいメンバーがチームに加入したりする時期
-
混乱期: チームが作業の進め方について意見が衝突する時期
-
統一期: グループ内の役割や関係性についてチーム メンバーの認識が一致する時期
-
機能期: チームの実力が十分に発揮され、生産性が最大化されてチーム メンバー間の軋轢が最小化される時期
これを見れば、発展の初期段階にいるチームが、より長く共に作業をしているチームよりもコンセンサスを形成するのに時間がかかるのは当然であることが分かります。
スプリント プランニングが一部の批評家によって時間の無駄と見なされる理由は、この順応という要因にあるのかもしれません。逆に、スクラムのエキスパートは、スプリント プランニングはあらゆるスプリントに先行して行われる重要な活動だと言います。ひとつには、スプリント プラニングによってスプリントの効率が向上し、開発者が処理できる以上の作業を引き受けることを防ぐことができます。また、このプロセスによって、スプリントの成果物に関してプロジェクトのオーナーとコンセンサスを形成できます。さらに、アジャイル開発者は自分の仕事に対する権限を認識することができ、厳しい要求に常に自分の作業能力を合わせているように感じることを防ぐことができます。
“It's vitally important that the team drives the sprint goal and commits to something it can deliver. As much as the product owner wants to hear team members promise the moon and the stars, they can always bring in more work later if they complete what they’ve committed to,” says Jeff Crowl, a Scrum Master and Agile coach who has worked at Nike, T-Mobile, and other companies. “This goes double for a scaled enterprise, where other teams' sprints could actively depend on the work being done in two weeks,” he notes
スプリント目標の定義は成功に不可欠
エキスパートによれば、スプリント目標の定義に取り組む労力は、スプリントによって組織とその顧客に最大限の価値を提供できるようにチームを支援するという形で実を結びます
チームはプロダクト オーナーと協力してスプリント目標を記述し、目標の記述は簡潔 (ほんの数行程度) に留めます。
Richard Hundhausen, President of Accentient Inc., which coaches companies in Scrum, says that the sprint goal is crucial: “I’d say the most common mistake is not collaborating with the product owner to create a sprint goal. Scrum teams typically jump right to forecasting without any consideration for a common theme for the work (the sprint goal). Without having a sprint goal, what will the Scrum team commit to? During the daily scrum, what goal will the development team plan their next 24 hours around?”
Scrum Trainer David Sabine of Agile consultancy Berteig says that without a clearly defined sprint goal, participants will struggle to determine what to tackle in the sprint. “The most common mistake in Sprint planning is that the team fails to achieve a clear sprint goal, making it impossible for team members to regulate the types of activity that belong in the sprint and the types of activity that do not,” he says.
一般的な目標と同様に、優れたスプリント目標は SMART (具体的 (specific)、測定可能 (measurable)、達成可能 (achievable)、現実的 (realistic)、期限付き(time-bound)) です。たとえば、オンライン フリーランス プラットフォームの開発チームにとっての優れたスプリント目標は、「ある税年度に得られるフリーランスの所得証明を提供する収益レポート ジェネレータを作成する」や「フリーランサーやクライアントにサードパーティのメッセージング サービスを利用させるのではなく、プラットフォーム内にマルチメディア メッセージング インターフェイスを作成する」のようになります。目標を明確に記載することで、スプリントに直接関与していない人に目標と進捗を簡単に伝えることができます。
スプリント目標の記述には、いくつかの考慮事項があります。たとえば、単一のスプリント内で達成するように設計された低位の目標は、高位の戦略的目標や製品の長期的なビジョンにどのように影響しますか？製品バックログのタスクのうち、どのタスクがスプリント目標に関連し、スプリント バックログに含める必要がありますか？また、スプリントの目標は、利用可能なリソースと開発者の数に基づいて達成可能かつ現実的ですか？稼働できる時間を考える際には、休日、チーム メンバーの休暇、会社のイベントを考慮に入れる必要があります。
スプリント目標は単なる形式的な完了項目ではなく、スプリントが実際に進行したら忘れられてしまうものでもありません。スプリント中に完了するべきすべての作業の方向性を定義するだけでなく、スプリント後のレビューでスプリントの成功を評価する基準でもあります。そのため、リソースを考慮してチームが実際に達成できる目標を決めることが必要です。
スプリント バックログの定義によってチームの作業計画が決まる
スプリント バックログは、スプリント中に完了するタスクのリストで構成されます。スクラム チームとプロダクト オーナーが協力して作成しますが、後者は通常、細かいスプリント プラニング プロセスには関与しません。定義上、スクラム チームは自己組織化されているため、チーム メンバーがプロセスを推進します。多くの場合、プロダクト オーナーは、チームがタスクをどのように克服すべきかを知る立場にありません。実際、プランニングのこの部分にオーナーが密接に関与することは、逆効果になる場合もあります。
そうではなく、通常プロダクト オーナーの役割はスプリント目標を指定し、スプリント バックログの候補アイテムを準備し、これらのアイテムの要件を記述し、両当事者が合意に達するまでバックログの構成について開発者チームと交渉することです。
もちろん、プロダクト オーナーは、スプリント バックログのアイテム、その順序、達成方法について質問する権利を持っています。スクラム チームは、デリバリにコミットするバックログ項目のリストと、これらのアイテムを完了するために必要なタスクとサブタスクのリストの両方を準備します。このプロセスでは、チームは各バックログ項目を完了するために必要な労力も見積もります。通常はシャツ サイズやストーリー ポイントなどの簡潔なサイズ見積り方法を使用します。
Ron Madison, a Scrum Master at PayPal, says that it’s important at this stage to know what work comprises each task. “A mature team does tasking of stories before sprint planning, including both development and quality assurance,” he points out.
通常、単一のスプリントの作業量にはバッファー時間も組み込み、処理可能にする必要があります。スプリント キャパシティの 20% が「余裕時間」として割り当てられることも珍しくありません。これを行うために、チームは単一のスプリント中に完了した作業量をストーリー ポイントで示した、スプリント速度と呼ばれるメトリックを使用します。通常は最新のスプリントの数字を使用します。前のスプリントの速度が次のスプリントの最も正確な予測因子であると考えられるので、このプラクティスは「昨日の天気」を使用すると呼ばれています。スプリント速度は、チーム メンバーの空き状況とスクラム チームの構成に基づいて調整されます。
“The most common mistake is overfilling a sprint with work,” says Troy Magennis, President of Focused Objective, a software development consulting firm. “If you are doing lots of first time work, uncertainty will be very high, so it's preferable to acknowledge that fact up front and leave space to get customer satisfaction for and high quality from the stories you do choose. The second and third biggest mistakes of sprint planning are also overfilling. Don't let quality suffer because you bite off more than the team can chew.”
スプリント プランニングは、WHAT ミーティングと HOW ミーティングの 2 つのフェーズに分けられます。WHAT ミーティング中にスプリント目標が定義され、スプリント バックログが作成され、チームのキャパシティが決定されます。HOW ミーティング中に、スクラム チームは各バックログ項目を完了するために必要なタスクのリストを作成します。ソフトウェアでは、これらのタスクは通常、設計、実装、テスト、文書化にまたがり、各タスクは完了にわずか数日しかかかりません。タスクに数日以上かかる場合は、スプリント バックログのアイテムがスプリントの作業として大きすぎることを意味し、分割する必要がある可能性があります。
次に、スクラム チームはバックログ項目の完了に必要な時間の作業量をマンアワーで見積り、スプリントのアクティビティの合計期間を計算して予測します。スクラム チームのキャパシティに基づいて、スプリント中にメンバーより多くの作業に取り組めると (またはより少なくする必要があると) 感じた場合、メンバーは作業範囲を拡大または縮小するためにイテレーションの調整をリクエストできます。
Mike Cohn, President of Mountain Goat Software, cautions teams against overplanning. “The biggest problem I see during sprint planning is teams taking it too seriously. They do this by trying to identify every task they'll need to do. That level of detail isn't needed. Identify enough tasks to know you're selecting the right product backlog items, but that doesn't mean you have to include every little task. ‘Get in, get’ out should be the rule for sprint planning,” he says.
スプリント ミーティングの参加者
スプリント プランニング セッションには、スクラム チーム、スクラム マスター、プロダクト オーナーの 3 つの主要な 関係者からの意見が反映されます。
スクラム チームは、プロジェクトの実際の作業を引き受ける開発者で構成されています。スプリント プランニング ミーティングでは、1 回のスプリントで何ができるか、何をするべきかを見積り、議論するのがチームの仕事です。その後、スクラム チームはスプリントの目標を達成し、プロジェクトに取り組み、スプリント プランニング中に明確にされた要件を満たす新しいイテレーションを確実に実施することにコミットします。
スクラム マスターはスクラム チームの進行役であり、調整係であり、コーチです。一般的に、スクラム マスターはチームの仕事がどのように包括的な戦略的目標、長期的な目標、顧客関係に影響するかを理解している、年長の経験豊富な開発者です。スクラム マスターは、チームの外部関係 (プロダクト オーナーとの関係を含む) を管理し、チームがアジャイル開発の原則に従うようにします。スプリント プラニング セッションでは、スクラム マスターがスクラム チームをガイドして各スプリントに適した目標を設定できるようにし、開発者とプロダクト オーナーの間の交渉者の役割を果たします。
Laurens Bonnema, a Scrum Consultant with Xebia, says the Scrum master’s role is crucial to making sure the team acts as “value-driven problem solvers.” Says Bonnema, “An experienced Scrum master will help the team recognize the importance of a sprint goal and work with it to craft one at the start of the sprint planning. Usually, just asking the question, ‘So, what shall we focus on next sprint?’ will help a team select and slice the work.”
プロダクト オーナーは、プロジェクトの主な関係者であり、その人物または当事者のためにプロジェクトが構築されています。プロダクト オーナーがスプリント プランニングにどの程度関与するかはさまざまですが、低位タスクのプランニングには干渉しない傾向があります。代わりに、スプリント目標を示し、スプリント バックログのアイテムを選択して優先順位付けし、各アイテムの受け入れ要件を規定する権限を有します。
スプリント レビュー ミーティングの目標
皮肉なことに、スプリント プランニングは前のスプリントの終了と同時に始まります。各スプリントの終了時にレビュー ミーティングを開催し、スクラム チームが達成したことをレビューし、新しい機能と特徴のデモを行います。
通常、スクラム チーム、プロダクト オーナー、スクラム マスター、組織内の他の開発者、マネジメント、その他の関係者がスプリントレビューに参加します。くだけた雰囲気を作ることで、会話は円滑に進みます。
このセッションでは、スプリント プランニング ミーティングで設定したスプリント目標に照らしてチームの作業を評価します。チームは各スプリント バックログ項目を達成しましたか？包括的なスプリント目標を達成しましたか？次のスプリントに適用できる教訓はありましたか？
スプリント プランニング ミーティングの準備
スプリント ミーティングを開始する前に、製品ロードマップを確認することをお勧めします。この戦略的文書は、長期間にわたる一連のスプリントとイテレーションで製品がどのように進化するかをまとめたものです。最終的にスプリント バックログに入るアイテムは製品ロードマップに沿っている必要があるため、ロードマップを常に念頭に置いておく必要があります。スプリント バックログ項目が製品ロードマップに沿っていない場合、製品が方向性を失う危険があります。
また、スクラム チーム、スクラム マスター、プロジェクト オーナーの各代表者と事前プランニング ミーティングを開催する必要があります。このミーティングは、メインのスプリント プランニング ミーティングの数日前に開催され、全員がバックログをグルーミングする機会を得ることができます。バックログ グルーミングとは、バックログ項目の優先順位付け、見積り、詳細化、受け入れ基準の決定を行うプロセスです。プラニング セッション自体を迅速化し、必要な作業量と利用可能なキャパシティをより正確に一致させることで、スプリント中の生産性を向上させることができます。
“One of the biggest mistakes that I see related to sprint planning is an overall lack of preparation and solid understanding of the stories prior to the meeting. This [problem] can cause a myriad of issues. Teams need to fully understand a story before they can commit to the work, and, most often, a single one-to-four-hour meeting just isn’t going to cut it,” says Jennifer Guilbert, a Scrum Master with Capstone Consulting.
「次のスプリント プラニング ミーティングに先立ち、プロダクト オーナーとチームが次のスプリント バックログに追加されたストーリーをレビューし、質問を投げかけ、疑問を解消するために、スプリント中のチェックポイントやグルーミング アクティビティを追加することをお勧めします。これにより、スプリント プラニングの効率性を向上し、時間を半分に短縮できます。」と同氏は言います。
スプリント バックログ テンプレートをダウンロード - Excel
バックログ上のアイテムの優先順位付けに納得できるかどうかを誰もが確認できるため、プランニング前のミーティングに参加することで他の主な関係者もメリットを得られる可能性があります。また、完了したバックログ項目に合わせて必要なデザインの変更について考慮することができるように、UX デザイナーを参加させる適切なタイミングでもあります。
バックログ項目の優先順位付けを決定するテクニックを使用する場合、通常バグ修正と欠陥の修復は、スプリント バックログで最も優先されます。もう 1 つの一般的な方法は、ビジネスに向けた優先順位付けを使用することです。バックログのどのアイテムがビジネスに最も利益をもたらし、したがって優先順位を最も高く割り当てるべきかを考えます。バックログ項目に関連するリスクやそれによって軽減されるリスク、アイテムによって創出されると予想されるビジネス価値の量など、いくつかの要素を検討する必要があります。これらのメトリックが不足している場合は、各アイテムを「対応必須」、「対応すべき」、「できれば対応」または「対応したい」に分離する MosCow 分析も役立ちます。もちろん、バックログの優先順位付けに対するスクラム マスターの経験も活用する必要があります。スクラム マスターはチームのアドバイザーを務めるためです。
また、この種の事前プランニング ミーティングは、プロダクト オーナーが、バックログのアイテムがチームの準備完了の定義満たしていること (つまりすぐに実行可能であること) を確認するためにも役立ちます。スプリントでは時間を無駄にする余地がほぼないため、開発チームはそのバックログ項目に取り組む準備ができているかどうかを示す一連の基準を設定します。
通常、最も取り組みやすいバックログ項目を最初に準備します。一般的なタスクに取り組む一般的なチームの場合、準備完了の定義には次のいずれかまたはすべてが含まれる場合があります。ストーリー ポイントが割り当てられている。テスト可能な例が作成されている。受け入れ基準が定義されている。確実な準備の定義を表すシンプルな頭字語の 1 つは INVEST (独立している (independent)、交渉可能 (negotiable)、価値がある (valuable)、評価できる (estimable)、小規模 (small)、テスト可能 (testable)) です。INVEST を使用して検証されたストーリーは、スプリント バックログに移動することができます。
同様に、プロダクト オーナーは、バックログ項目の受け入れ基準を確立することで、プランニング ミーティングの時間を節約できます。バックログ項目の実装によって何を達成することが必須で、達成すべきで、達成できるかをシンプルかつ客観的に説明することで、本番のプランニング ミーティングでの受け入れ基準の議論を加速できます。
“The most common mistakes I see in sprint planning are stories that don’t have an acceptance criteria and product owners not showing up. Another mistake I see on the part of Scrum masters is trying to assign all stories to a specific team member,” says Aleksandr Kofman, a Scrum Master at information provider Elsevier.
スプリント プランニング ミーティングのステップ
一般的なスプリント計画ミーティングの進め方は次のとおりです。
-
全体像を描く: ミーティングを開始する前に、スクラム マスターは、チームが達成しようとしている目標の概要と、それが製品の戦略的目標やロードマップにどのように関連するかを再度チームに伝えます。また、中期的な製品の方向性に関する文脈を明らかにするために、スプリント 2 回分のアイテムについてプロダクト オーナーに話をしてもらうことも有効です。
-
全員に情報を提供する: このタイミングで、次のスプリントの参加者が把握しておくべき情報を伝えます。バックログへの最近の追加、チーム メンバーの空き状況の変更、または新しい関係者の意見などはすべて、この時点で共有できます。
-
次のスプリントの目標速度を提示する: 速度とは、スプリント中に完了したユーザー ストーリーの総数です。通常、この数字は最後に完了したスプリントから取得します (昨日の天気の原則)。それ以降にスクラム チームのメンバー構成 (人数ではなく) が変更された場合は、過去 3 回のスプリントの平均速度を使用します。これがチームの最初のスプリントの場合、大まかな数字の目安は開発者 1 人につきスプリントあたり 8 ストーリー ポイントです。この数字は後でいつでも調整できます。
-
チーム キャパシティを確認する: チーム キャパシティは、スプリントに必要な合計マンアワーとして計算されます。したがって、10 人のスクラム チームが 10 日間のプロジェクトで勤務日につき 10 時間作業をする場合、キャパシティは 1,000 時間になります。しかし、チームは通常ダウンタイム、オーバーヘッド、勤務時間の損失を考慮して、最大キャパシティから 20 ～ 40% を差し引きます。また、バックログ項目間の依存関係が避けられないため、実際のキャパシティは遅延したタスクがその後のタスクを後ろ倒しにする一種のドミノ効果によってさらに減少する可能性があります。スプリント速度やチーム キャパシティに影響を与える要因が予想される場合は、この段階で記録してください。
-
完了の定義を確認する: 完了の定義は、スプリントの終了時におけるイテレーションの成果がどのようなものかを示すスナップショットです。作業を実行する人と検査する人が、スプリントが始まる前に完了の定義に合意することが重要です。
-
どのプロダクト バックログ項目をスプリント バックログに移動するかを決定する: この段階でスクラム チームは、いずれかのバックログ項目が大きすぎて 1 つのスプリントで完了できず、延期する必要があるかどうかも決定します。
-
リソースのニーズを判断し、誰が何をするのかを決定し、所有する作業を見積る: 作業が多すぎてスクラム チームが合理的に処理できない場合、この時点でスクラム マスターにとって明らかになります。作業を割り当て、個人の割り当てがそれぞれのキャパシティと一致していることを確認します。
-
受け入れ基準を定義する: 受け入れ基準は、バックログ項目が正常に完了したかどうかを示す測定可能な基準です。これらの基準を指定することはプロジェクト オーナーの特権ですが、スクラム チームはスクラム マスターを介して交渉できる可能性もあります。
-
プランニング中に特定された想定事項、新しい問題、依存関係を確認して記録する:この情報は製品バックログに統合する必要があります。
-
コンセンサスを求める:これはスクラム マスターの特権です。ほぼ同時に、スクラム チームとプロダクト オーナーは、これがスプリントに最適な計画だと考えるかどうかを表明します。
-
関連するタスクについて詳しく説明する: スクラム チームが、特にスプリント バックログのアイテムの詳細に関する情報が必要な場合は、この時点で必要な質問をしてユーザー ストーリーを詳細なタスクに変えられるようにします。
スプリント プランニング ミーティングを準備して実施する方法
最初のスプリント プランニング ミーティングを開催しようとしている場合も、ミーティングの生産性を高めようとしている場合も、何をカバーする必要があるかを知ることは重要ですが、流れを確定し、準備をしておく必要もあります。
1 か月間のスプリントの場合は、スプリント時間の各週に 1 時間のミーティング時間、合計約 4 時間を確保しておく必要があります。対面でミーティングを行うことが理想ですが、リモートのチーム メンバーがいる場合は、会議ツールがうまく機能していることを確認してください。
対面で集まる場合は、全員を収容できる十分な広さのワークスペースが必要です。付箋、ホワイトボード、電子ツールなどの視覚的なツールを用意してください。(バックログ項目を表すために、いくつかの異なる色の付箋を用意します) また、チームはしばらくその場にいるため、参加者が疲れてしまわないように軽食とコーヒーも必要です。
スプリント プランニング ミーティングのアジェンダをダウンロード
会議を開始する前に、スプリントの目標と速度をミーティング ルームに張り出し、全員が参照できるようにします。
“Sprint planning should be highly interactive,” says Certified Scrum Trainer Adam Weisbart, who has worked with Oracle, Symantec, Hewlett Packard, and Pfizer. “If you use a software tool to wrangle Scrum artifacts, print out your product backlog items and tape them to the wall instead for this meeting. Have people close their laptops and shut off their phones, and have face-to-face conversations around these physical items. You'll be amazed at how much more life this brings to your meeting and your product,” he adds.
付箋を使用してバックログ項目を記録する: アイテムの種類ごとに異なる色の付箋を使用します。ユーザー ストーリー用、タスク用、バグ用の少なくとも 3 つの色が必要です。その後、優先順位の高い順に壁やボードに付箋を貼ります。リモートのチーム メンバーのために、この視覚的なバックログを再現する必要があります。
ミーティングを開始する準備ができたら、最後のスプリントでチームが達成したことを祝し、良いスタートを切りましょう。次に、スクラム マスターまたはプロダクト オーナーが、最後のスプリントから残ったものを含め、スプリント バックログのストーリーを紹介します。事前プランニングで行わなかった場合は、ストーリーのサイズを見積る必要があります。これを行う方法はいくつかあります。チームによって、T シャツ サイズ (XS、S、M、M+、L、XL、XXL、XXXL) を使用してもよいし、フィボナッチ数列 (1、2、3、5、8、13、21) を使用してストーリー ポイントを割り当ててもよいでしょう。
どのサイズ設定システムを使用する場合でも、生の値よりも相対的な値が重要です。2 つのストーリーから始め、どちらが大きいかを決め、順番に配置します。次に、3 番目のストーリーを取り上げ、他の 2 つのストーリーと比較した大きさを決定し、ランキングに追加します。これを続けていきます。ストーリー ポイントの合計は、チームの速度よりも小さくする必要があります。また、スプリント バックログに入る製品バックログ項目も、作業の準備が整っているかどうかを検証する必要があります。
スクラム チームにとって、各ユーザー ストーリーの解析には長い時間がかかる場合があり、考慮すべきステップがいくつかあります。たとえば、このストーリーは最新か、または定義が変更されたか。考慮すべき新しい情報があるか。ストーリーの見積りはまだ有効か。
Scrum Master Andrey Grubin of gaming company PlasmaNet says stories should be evaluated in the context of the sprint goal. “Try to determine from capacity, past velocity, and an overall comfort level within the team whether the proposed stories are achievable within the sprint. Don’t hesitate to consult the product owner if there are any questions or concerns around the proposed stories,” he recommends.
ストーリーの定義が固定されたら、タスクに分割する必要があります。(これらのタスクの中には、それ自体がユーザー ストーリーになるものもあります) チームは、これらのタスクを処理するために必要な専門スキルセットがあれば決定し、ストーリーのテスト方法も検討します。
ストーリー ポイントや速度と同様に、タスクの推定期間はスプリントにおけるチームのキャパシティよりも小さくする必要があります。スプリント バックログに移動したタスクとユーザー ストーリーには、勤務日の数や、チーム メンバーが休日を取るかどうか、またはパートタイムでスクラム チームで作業するかどうかを考慮して、期限が割り当てられます。
バックログに組み込まれるのはユーザー ストーリーやその構成タスクだけではありません。バグ修正も含まれるため、スクラム チームのキャパシティの一部を割く必要があります。しかし、各バックログ項目がどの程度のスペースを取るか、どのように判断すればよいのでしょうか。1 つの方法は、バグ修正に対して、固定された割合のキャパシティ (たとえば 20%) を割り当てることです。もう 1 つは、バグ修正をユーザー ストーリーにつなげ、ユーザー ストーリーのようにサイズと優先順位を設定することです。
最後に、スクラム チーム、スクラム マスター、プロダクト オーナーは、新しいイテレーションの品質を保証するための何らかのテスト メトリックを含む完了の定義を作成します。
スプリント プランニング セッションは、目標とするいくつかの成果を達成して終了することが理想です。これには、以下が含まれます。スクラム チームが目標に納得し、目標を製品の戦略的ビジョンとロードマップと一致させる。スプリント計画を十分に文書化する。バーンダウン チャート(残っている時間に対して残された作業を書き出したグラフ) を作成して、計画された作業の進捗を示す。スクラム チームの各開発者に、スプリントが始まったら何に取り組むのかを正確に知ってもらう。
スプリント バックログを整え、スプリントの目標を念頭に置いたら、スプリントを開始する準備が整いました。
アジャイル マーケティングのためのスプリント プランニング
ソフトウェア開発者は典型的なアジャイルのプロフェッショナルですが、唯一の存在ではありません。多くのマーケティング チームも熱心にアジャイルを導入しています。
もちろん、マーケターは固定されたイテレーションでソフトウェアをリリースしません。マーケターが取り組んでいるのは、さまざまなアクティビティで構成される継続的な (多くの場合は長期的な) プロジェクトです。多くの場合、新しい一連の取り組みに対してそれぞれ明確な目標を念頭に置き、短期と中期の優先事項を常に調整する必要があります。
したがって、マーケターにとってアジャイル手法を採用することは、変化する市場環境に組織的に対応しながら効率を最大化し、明確に定めた目標に向かって進む手段です。
ほとんどの場合、ソフトウェア開発とマーケティングのスプリントおよびスプリント プランニングは非常に似ています。しかし、いくつかの大きな違いがあります。
1 つ目は、マーケティングのスプリントの長さはソフトウェア開発のスプリントよりも短い傾向にあることです。一般的なマーケティング スプリントは 2 週間以上かかることはありませんが、ソフトウェア開発では 1 ～ 2 か月続くスプリントは珍しくありません。
2 つ目は、スプリント期間中のスプリント バックログの変更は、ソフトウェア開発よりもマーケティングにおいて一般的であることです。この違いは、ソフトウェア開発に関わる技術的なタスクによって課せられるより厳格な制約に関連します。マーケティングはより流動的な傾向にあります。
3 つ目は、マーケティングのスクラム チームはソフトウェア開発のスクラム チームよりも幅広い専門分野を持つ傾向にあることです。前者にはより多くの分野が関わるためです。
スプリント プランニングのベスト プラクティス
エキスパートは、スプリント プランニング ミーティングを最大限に活かすためのベスト プラクティスを推奨しています。
ミーティングの招待状を出す際には、アジェンダを含めます。また、製品バックログ内の候補のユーザー ストーリーへのリンクを追加して、開発者がスプリント ミーティングの前に確認できるようにすることを検討してください。
プロダクト オーナーが製品バックログから候補のユーザー ストーリーのリストを準備する際には、スクラム チームのキャパシティを超えるストーリーを選択する必要があります。これは、スクラム マスターとスクラム チームが一部のユーザー ストーリーを却下したり、後のスプリントに延期したりする可能性が高いためです。プロダクト オーナーがチームの最大キャパシティを下回るストーリーを選択した場合、ストーリーが却下された場合はスプリント中のキャパシティを無駄にすることになります。
スプリント プランニング ミーティングでは、責任者はプロダクト オーナーではなくスクラム マスターであることを忘れないでください。スクラム チームと同様に、プロダクト オーナーはどちらかといえばミーティングの参加者です。プロダクト オーナーは開発者の質問に答え、ユーザー ストーリーを説明し、スクラム マスターの調停の下に受け入れ基準を交渉します。
また、最も効果的に貢献する方法や、他の参加者から期待できることとできないことを伝えておくことも有益です。たとえば、プロダクト オーナーはスプリント目標の作成を主導し、スプリントの範囲を定義し、完了の定義を含む各ユーザー ストーリーを非常に詳細に説明し、製品バックログの優先順位付けを担当します。
スクラム マスターはミーティングの流れを決定し、スプリントの速度や実際のチーム キャパシティなど、主要なメトリックを交渉します。また、スクラム マスターはスプリント バックログを最終的に確定し、プロダクト オーナーとスクラム チームの間の適度な交渉も主導します。
“The most common mistake made during sprint planning is not having a clear idea about the team's capacity and, hence, ending up with inconsistent velocity, which, again, induces errors on estimated commitments to be made by the team,” says Parashuram Bellikatti, a specialist in Agile transformations and Director of the Global Agile Centre for Excellence in Bangalore.
スクラム チームは、今後のスプリントに必要な情報を問い合わせ、合理的に達成できることを納得したスプリント バックログにコミットします。また、スプリント中のいずれかの期間に稼働できなくなる場合は、スクラムマスタに通知することもチームの義務です。
アジャイル コーチのケビン・ブルナー (Kevin Brunner) 氏によれば、スプリント プランニングが上手くいかない一般的な原因の 1 つはバックログの責任者です。責任者がミーティングの準備ができていない場合やチームが単独で意思決定を行うことを信頼していない場合、チームのマインドセットはコミットメントではなく一種の回避になります。特に開発者はミーティングが時間の無駄だと言うかもしれません。ユーザー ストーリーが具体化されていないため、または結局スクラム マスターやプロダクト オーナーが一方的にすべての決定を行うので参加が必要ないためです。
ブルナー (Brunner) 氏は、健全なチームの機能を育てるためにスクラム マスターは 3 つの原則に従うことができると言います。
-
視覚化: イテレーションが正常に完了したスプリントの終わりまで早送りして視覚化し、そこから逆算して受け入れ基準を交渉し、完了したイテレーションを実現するために必要な情報を抽出します。視覚化によって、チームはその取り組みが形になった具体的な最終製品を思い描くことができます。
-
育成: 合意を得てチームの意思決定を行い、チーム メンバーの意見に耳を傾け、尊重する習慣です。また、育成によってチームが意思決定を行うために必要な時間を確保し、スコープや時間の見積りなど、スプリントの主要な側面に対する賛同を得ることができます。
-
振り返り: スプリントが終わったら振り返って考え、何が上手くいき、何が上手くいかなかったのか、どうすれば改善できたかを検討する習慣です。
アジャイル コーチのトニー・ソロミタ (Tony Solomita) 氏によれば、健全なチームの機能は次の 3 つの習慣によって定義されます。プランニング ミーティングの前にバックログを準備すること、スプリント バックログの見積りと確定を行うプロセスで全員の意見に耳を傾けること、そして特定の機能が必要な理由に対するプロダクト オーナーの権威とその機能の達成方法に関する開発者の権威を尊重することです。
スプリント プランニングに関してよく寄せられる質問
スプリント プランニングに関して最もよく寄せられる質問は次のとおりです。
タスク間の依存関係の最適な処理方法は何ですか？タスクの依存関係による潜在的な時間の無駄の影響を軽減する方法はいくつかあります。まず、スプリント プランニング ミーティング中にタスクを計画することでユーザー ストーリーをタスクに分割できるため、複雑な依存関係を積極的に最小限に抑えたり排除したりできます。2 つ目は、可能であれば依存するタスク間にバッファー時間を構築することです。3 つ目は、疎結合で適応可能なデザインやモック オブジェクトなどの開発テクニックを使用することで、開発者は依存関係の影響に対処できます。4 つ目は、開発者が互いに近接して仕事をしてコミュニケーションを促進することで、依存関係に関連する問題を未然に回避できます。
各チーム メンバーはどれくらい作業を引き受ける必要がありますか？昨日の天気の原則を使う場合、各チーム メンバーは最後のスプリントで処理したストーリー ポイントの総数を超えないように作業を引き受ける必要があります。
チームの規模が異なる場合、イテレーションはどのように計画されますか？チームの規模が繰り返し変更されることは理想的ではありませんが、避けられない場合もあります。チームの規模が変化した場合は、最後のスプリントで開発者ごとに取り組んだストーリー ポイントの平均数を計算し、次のスプリントに参加する開発者の数に掛けてスプリント速度の大まかな数字を割り出します。具体的に誰がチームを去り、誰がチームに加わるかに基づいて、この数字をさらに調整する必要がある場合もあります。
ミーティングメールの作成に費やされる時間などのオーバーヘッドはどのように考慮されますか？オーバーヘッドはチームによって異なるため、オーバーヘッドを計算するための経験則はありません。ほとんどのチームは、各スプリントのオーバーヘッドに費やされる時間は一貫しており、前のスプリントのスプリント速度がオーバーヘッドに費やされた時間を正確に反映していると仮定しています。
バグ修正はどのように考慮する必要がありますか？これに対応するにはいくつかの方法があります。1 つはバグをユーザー ストーリーとして扱い、スプリント バックログの他のアイテムと同様に関連する作業量を見積ることです。もう 1 つのよりリスクの高いアプローチは、バグにストーリー ポイントを割り当てず、チームの速度を下げないようにすることです。このアプローチのリスクは、各イテレーションでバグ修正に同じ量の作業を行う場合にのみ機能することです。バグ修正に関する作業の量が異なる場合、スプリントごとに速度が大幅に変化し、将来のスプリントの計画が非常に困難になります。
イテレーションが常に同じ長さである必要があるのはなぜですか？簡潔に言えば、答えはリズムと一貫性です。スプリントのシーケンスは、定期的で予測しやすいサイクルに従えばはるかにスムーズに進み、スプリント プランニングを大幅に簡素化できます。
テストとドキュメント作成に費やされる時間はどのように考慮されますか？これを行う最も簡単な方法は、テストとドキュメント作成に費やされる時間をユーザー ストーリーごとに個別のタスクとして含めることです。テストとドキュメント作成用にスプリント バックログに別のアイテムを作成す方法もあります。
イテレーション プランニング中に機能の見積りを修正する必要がありますか？当初の見積りが大きく誤っている場合にのみ修正が必要です。
イテレーションにタスクの見積りを修正する必要がありますか？いいえ。イテレーション プランニングが完了したら、タスクの見積りは変更しません。もちろん、スクラム マスターは、チームがタスクの変更を選択した理由をメモし、この情報を将来のスプリント プランニングに反映できるようにする可能性が高いです。
すべてのチームが同じイテレーション スケジュールで作業する必要がありますか？これは、並行して作業するスクラム チームの数と、サポートスタッフの空き状況によって異なります。複数のチームが同時に開始および終了するイテレーションに取り組むことに対する制約がなければ、結果として得られる同期性は管理の面で大きなメリットとなります。チームがスプリント プランニングに関して互いに調整を行うため、あるチームの作業によって別のチームのスプリント バックログを変更する必要が生じるというリスクを減らすことができます。しかし、実際にはスクラム チームは個別に作業をするものではなく、複数のスクラム チームでサポートの役割を務めるスタッフの数も限られているため、イテレーションの開始日と終了日をずらすことが好まれます。
一般的なスプリント プランニングのミスと警告サイン
経験豊富なスクラム マスターは、スプリント プランニングが予定よりも順調に進んでいないことを示す警告サインを把握しています。ここでは注意するべき警告サインを紹介します。
チームが繰り返しスプリント バックログを完了できない場合 (ユーザー ストーリーを何度も次のスプリントに持ち越す場合) は、グループが速度を過大評価し、過剰な作業を引き受けているサインです。計画が正確になるように (実際に役立つように)、スクラム マスターはスクラム チームの速度を下方修正する必要があります。
しかし、同じ機能が次のスプリントに繰り返し持ち越さられている場合、チームは特定のユーザー ストーリーやバグ修正に取り組むことを意図的に避けていると考えられます。このような状況では、ユーザー ストーリーやバグに関して、スプリント プランニング中に持ち上がらなかった問題があるかどうかを探ることが推奨されます。
スプリント バックログに従わない場合は過剰設計が起こる可能性もあります。これは、開発者が適切な範囲を超えて必要以上の作業をしてしまうことを意味します。この場合、リクエストされた機能の要件を見直し、チームが不要な労力を費やさないようにする必要があります。
避けるべきこと: スプリント プラニングにおける一般的なミス
スプリント プランニング セッションは、以下の一般的な落とし穴によって効果を失ってしまう可能性があります。
-
プロダクト オーナーが開発者の意見を聞くことなくスプリント バックログを作成する: この場合、スクラム チームは作成にまったく意見が反映されていないバックログにコミットすることになります。これにより、プランニング プロセスへのエンゲージメントと、スプリントで定めた目標を達成できる可能性の両方が減少します。
-
スクラム マスターが候補のユーザー ストーリーをスプリント プランニング ミーティングで初めて開発者に示す: 不要な時間の浪費であり、プランニング ミーティングに予定よりもずっと長い時間がかかることになります。 バックログをグルーミングしておけば、ミーティングのアジェンダに候補のユーザー ストーリーを含めておくことはまったく難しくありません。INVEST 基準を満たしていないユーザー ストーリーがある場合も同様の問題が発生します。
-
チームが完了の定義に納得していない:このような場合、チームはイテレーションの終了時に不完全な製品をデリバリすることになります。この問題が迫っている可能性があることを示す兆候は、スプリント バックログのすべてのアイテムが一連の管理可能なタスクに分割されていないことです。
-
サブタスクが徹底的に見積もられていない: それぞれのタスクが相対的に正確に見積もられていないように見える場合、この問題が発生している可能性があります(非常に複雑なタスクがシンプルなタスクと比較して大きく見積もられていない)。
-
スクラム マスターがスプリント バックログを電子ツールに入力するのに時間がかかりすぎる: これは、スクラム チームがスプリントの初期に目安なしで作業し、実際の進捗状況を把握できないことを意味します。
-
候補のユーザー ストーリーがスプリント バックログに追加される前に他の関係者と議論されていない: このようなミスがある場合もやはり、スプリントの開始後に不満を持つ関係者によってバックログの変更がリクエストされる可能性があります。最初のスプリント バックログを承認した後でもプロダクト オーナーがこれを行う場合もあり、大きなフラストレーションを生むことになります。一部のスクラム チームによっては、ある程度のバックログの変更は事実上避けられない場合があります。この場合、いくつかの救済策が考えられます。1 つは、スプリントの長さを長くするか、スプリントのキャパシティを意図的に小さく見積ることで、作業が追加された場合に備えて余白を多く取っておくことです。作業が頻繁に中断されるチームの場合、アクティビティが意図した目的を真に達成することができないため、割り切ってスプリント プランニングに費やす時間を減らすのが最善の解決策かもしれません。
-
スクラム チームがタスクとサブタスクを十分に詳細化していない: これは通常、チームがプランニングに飽き飽きしていて、すぐに作業をしたがっているサインです。詳細化が不十分であると、タスクが予想以上に時間がかかることに開発者が気づいた場合に見積りが機能しなくなるというリスクがあります。
-
チームのメンバーがステップについて話し合うことに消極的: この場合、チームの他のメンバーが学ぶ機会を奪われてしまいます。
-
プランニングに責任を負うスクラム マスターがチームにいない: プランニング セッションのペースを管理するスクラム マスターがいないと、全員ができるだけ早く終了させようとします。その結果、まったく効果のないプランニング セッションとなったり、重要な詳細が無視されたりする可能性があります。
プロジェクト管理のための Smartsheet でスプリント プランニングを改善する
シンプルなタスク管理やプロジェクト プランニングから、複雑なリソース計画やポートフォリオ マネジメントまで、Smartsheet は共同作業の改善と作業速度の向上に役立ち、より多くの成果を上げるのに効果的です。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。