Jira のスクラム テンプレートにより最適なスプリントを計画
大規模なプロジェクトを全スプリント間で管理可能なタスクとマイルストーンに分割します。
Scrum.org の最高経営責任者、Dave West 氏による記事では、Scrum.org で説明されているとおり、スプリント計画セレモニーがまとめられています。Scrum.org は、アジャイルの世界においてスクラム フレームワークの公式ガイドとみなされているスクラム ガイドに基づきスクラムを教える団体です。以下の動画では、Jira の製品責任者 Megan Cook がスプリント計画に対する観点を話しています。
スプリント計画とは
スプリント計画は、スプリントを開始するスクラムにおけるイベントです。スプリント計画の目的は、スプリントの実行内容や作業の達成方法を定義することです。スプリント計画は、スクラムチーム全体でのコラボレーションを通じて実行されます。
スクラム において、スプリントとはすべての作業が完了するとされる設定期間のことです。しかし、作業を開始する前にスプリントを設定する必要があります。期間はどのくらいになるのか、スプリントの目標、どこから開始するのかを決定しなければなりません。スプリント計画セッションはアジェンダとフォーカスを設定することで、スプリントを開始します。正しく実行された場合、チームのモチベーションが上がり、課題に挑戦し、成功を収める環境が生まれます。誤ったスプリント計画は非現実的な期待をチームに課すことで士気を損なってしまいます。
What is the purpose of sprint planning?
The product owner describes the objective(or goal) of the sprint and what backlog items contribute to that goal. The scrum team decides what can be done in the coming sprint and what they will do during the sprint to make that happen.
How to run a sprint planning meeting?
- The What (何を) - プロダクト所有者はスプリントの目的 (または目標) と、その目標に寄与するバックログ アイテムについて説明します。スクラムチームは今後のスプリントにおいてできることと、実現のためにスプリント中に行うことを決定します。
- The How (方法) - 開発チームは、スプリントの目標を達成するために必要な作業を計画します。最終的に、結果として得られるスプリント計画は、価値と努力に基づき行う開発チームとプロダクト所有者間の交渉です。
- The Who (誰が) - プロダクト所有者または開発チームなしでは、スプリントは計画できません。プロダクト所有者は自らが求める価値に基づき目標を定義します。開発チームは、その目標をどのように達成できるか、または達成できないかを理解する必要があります。この事象でどれかが欠落していると、スプリント計画はほぼ不可能になります。
- Inputs (インプット) - 現在のスプリントの一部となる可能性のある「項目」のリストを提供するプロダクト バックログは、スプリント計画の優れた出発点です。チームはまた、インクリメントで完了した既存の作業を確認し、キャパシティを確認する必要があります。
- Outputs (アウトプット) - スプリント計画ミーティングの最も重要な成果は、チームがスプリントの目標と、その目標に向けてどのように作業を開始するかを説明できることです。これはスプリント バックログで可視化されます。
Who are the key participants?
Sprint planning meetings can't be done without the product owner or the development team. The product owner defines the goal based on the value that they seek. The development team needs to understand how they can or can't deliver that goal. If either is missing from this event it makes planning the sprint almost impossible.
What are the inputs?
A great starting point for the sprint plan is the product backlog as it provides a list of ‘stuff’ that could potentially be part of the current sprint. The team should also look at the existing work done in the increment and have a view to capacity.
What are the outputs?
The most important outcome for the sprint planning meeting is that the team can describe the goal of the sprint and how it will start working toward that goal. This is made visible in the sprint backlog.
スプリント計画ミーティングの準備
優れたスプリント計画イベントを実行するには、少しばかりの規律が必要です。製品所有者はしっかりと準備し、以前のスプリント・レビューから学んだこと、関係者のフィードバック、製品に対するビジョンを組み合わせなければいけません。そうすることで、スプリントの舞台ができあがります。透明性という観点では製品バックログは最新の状態で明確になっている必要があります。バックログ・リファインメントはスクラムにおける任意のイベントです。なぜなら、これが必要ないバックログも存在するためです。しかし、ほとんどのチームにとって、チームがスプリント計画前に集まり、バックログのレビューと見直しを行うことは有益です。
2 週間のスプリントを実行する場合、スプリントの最中にバックログを見直すためのミーティングを開催しましょう。スプリントから一歩引いた視点で、次に何をするか客観的に検討することはチームにとってメリットがあります。スプリント計画の準備に役立つだけではなく、現在の作業に対する別の観点も得ることができます。
スプリント計画の時間制限を設ける
スプリント計画は、スプリントの各週の 2 時間以上を占めるべきではありません。たとえば、2 週間のスプリントにおけるスプリント計画ミーティングは 4 時間以下にとどめるべきです。これは「タイムボクシング」と呼ばれ、チームがタスクを達成するための最大時間を設定することを意味します。この例では、スプリント計画がタスクにあたります。スクラム マスターは、タイムボックスが理解されたうえで会議が開催されることに責任を持ちます。タイムボックスが終了する前にチームが話し合いを完了できたなら、イベントは終了です。タイムボックスは許可される最大時間であり、最小時間は設けられていません。
作業ではなく、結果にフォーカスする
スプリント計画中は作業に集中してしまいがちです。どのタスクを最初に実行すべきか、誰が実行すべきか、どのくらいの時間がかかるのかということにフォーカスしやすいものです。複雑な作業の場合、最初の段階で把握している情報のレベルは低く、その情報すら推測に基づいている場合があります。スクラムは経験主義のプロセスです。つまり、前もって計画するのではなく、体験しながら学習し、情報をプロセスに組み込むのです。
スプリントの目標は、高レベルにおけるスプリントの目的を表しますが、バックログ項目も結果を念頭に書かれることがあります。ユーザー ストーリーは顧客の観点から作業を説明する良い機会です。以下のようなユーザー ストーリーは、欠陥、課題、改善において、発見された問題ではなく顧客が求めている結果に焦点を当てます。
明快で測定可能な結果をユーザーストーリーに追加すると、成果を明確に測定できるようになり、完了時期が把握できます。チームがフォーカスしている作業を可能な限り明確にすると、全員が作業開始に必要となる透明性を確保できます。たとえば、物事を曖昧なままにしておくことは、スプリント中に回答が必要な質問として何かを説明することよりも、多大な悪影響を及ぼします。
何かを知らないということと、曖昧であるということとは異なります。不明点を無視しないでください。難しい作業を行っている場合に不明点が出てくるのは現実的なことです。しかし、曖昧な言葉を用いて不明点を隠さないでください。その代わり、何かがわからない場合はそれを明確にし、理解を得るために作業を実施してください。
見積もりは必要だが、過信しないこと
スプリント計画にはある程度の見積もりが必要です。チームは、スプリントでできること、できないことを定義する必要があります。予測される努力とキャパシティです。見積もりはコミットメントと混同されがちです。見積もりとは、手元の知識に基づく予測です。ストーリー ポイント、あるいは T シャツのサイズ測定といった技術は、問題に対する異なる観点をチームに提供することで、プロセスへの付加価値を実現します。しかし見積もりは、どこにも存在しないはずの真実を見つけられるような魔法のツールではありません。不明点が多ければ多いほど、見積もりが正確である可能性は低くなります。
優れた見積もりを作成するには、信頼に基づいた環境が必要です。情報が自由に行き渡り、学習と改善を目的とした想定について議論される環境です。作業完了後に見積もりが否定的かつ抑圧的に使用された場合、今後の見積もりは、二度と誤らないように以前の見積もりより大きいものとなるか、チームが誤った場合の結果を気にして再検討を重ねるため、作成されるまでの時間がより長くなるかのどちらかでしょう。
T シャツのサイズ選びやストーリーポイントなど、異なる見積もりの技術の使用を検討しましょう。異なる技術によって、問題に対する別の観点が見えてくるかもしれません。
スプリント計画のベストプラクティス
Focus on a 'just enough' plan
スプリント計画の詳細で行き詰まると、その焦点は次のスプリント向けに「ちょうどいい」計画を構築することだという事実を忘れてしまいがちです。スプリント計画は、チームにとって厄介な問題であってはなりません。そうではなく、チームのフォーカスを重要な成果に向ける、組織のガードレールであるべきです。優れたスプリント計画は、結果を定義し、成功に向けた明確な計画を示すことで、関係者全員のモチベーションを維持します。しかし、計画しすぎるのは問題です。「スプリントの毎分について説明」するような完璧なスプリント計画を構築するのではなく、目標にフォーカスし、開始するのに必要なだけのスプリントバックログを構築します。次に、プロダクトバックログが整理されていることを確認し、早々にスプリント目標を達成すればチームが作業を開始できるようにします。
Prioritize goal-oriented planning
A good sprint plan motivates everyone by defining an outcome and a clear plan for success. Instead of building the most complete, “every minute of the sprint is accounted for” sprint plan, focus on the goal and build enough of a sprint backlog to get started.
Keep a flexible backlog
Ensure that the product backlog is ordered to allow the team to pick up work if they delivered on the sprint goal early.
Accept the empirical nature of scrum
スクラムは複雑な問題の解決を目的としたプロセスフレームワークです。複雑な問題には経験過程 (実行から学習すること) が必要です。経験過程は計画が非常に難しいものです。完璧な計画の構築はできません。完璧な計画ではなく、結果にフォーカスして実行を続けます。解決しようとしている問題自体が難しくても、それは難しいことではありません。
準備はできましたか? Jira でスプリントを使用する方法を学びましょう
