はじめに
みなさんはスクラムガイド読んだことありますか？
弊社はスクラム導入している アジャイルいいよね！ とかいう会話をしたことが一度でもある人は、
そんな長くないので原著スクラムガイドを読んでおくのはおすすめです。
PDF版の文書を、クリエイティブ・コモンズ CC BY-SA 4.0 のライセンス下で再配布しています。内容に変更はありません。
通勤中に何度も読んでいるときにPDFが大変だったなと思い、Webで見れるようにしたく書いてます。
(2017年版はこっち)
英語のweb版はこっち
スクラムガイド
1. スクラムガイドの目的
我々は 1990 年代初頭にスクラムを開発した。世界中の人たちがスクラムを理解できるように、スクラムガイドの最初のバージョンを 2010 年に執筆した。それ以来、機能的に小さな更新を加えながらスクラムガイドを進化させてきた。我々は共にスクラムガイドを支援している。
スクラムガイドにはスクラムの定義が含まれている。フレームワークの各要素には特定の目的があり、スクラムで実現される全体的な価値や結果に欠かせないものとなっている。スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。場合によっては、スクラムが役に立たなくなることさえある。
成⻑を続ける複雑な世界において、スクラムの利用は増加しており、我々はそれを見守っている。スクラムが誕生したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採用されている。そうした状況を見ると、我々も光栄である。スクラムが広まったことにより、開発者、研究者、アナリスト、科学者、その他の専門家もスクラムを利用するようになった。スクラムでは「開発者」という言葉を使っているが、開発者以外を排除しているのではなく、単純化のために使用しているだけである。スクラムから価値を得ているのであれば、そこにあなたも含まれていると考えてもらいたい。
スクラムを利用していると、本文書で説明しているスクラムフレームワークと適合するようなパターン、プロセス、インサイトを発見・適用・考案することもあるだろう。そうしたものについては、スクラムガイドの目的の範囲外である。これらは状況に依存しており、スクラムを利用する状況によって大きく異なるからだ。スクラムフレームワークで利用できる戦術にはさまざまなものが存在するが、それらはスクラムガイド以外のところで説明されている。
Ken Schwaber & Jeff Sutherland
2020 年 11 ⽉
© 2020 Ken Schwaber and Jeff Sutherland
This publication is offered for license under the Attribution Share-Alike license of Creative Commons,accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summaryform at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledgeand agree that you have read and agree to be bound by the terms of the Attribution Share-Alike licenseof Creative Commons.
2. スクラムの定義
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。
簡単に言えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。
- プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。
- スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。
- スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。
- 繰り返す。
スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を生み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する人たちの集合知で構築されている。スクラムのルールは詳細な指示を提供するものではなく、実践者の関係性や相互作用をガイドするものである。
スクラムフレームワークの中で、さまざまなプロセス、技法、手法を使用できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。
3. スクラムの理論
スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から生まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。
スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採用している。スクラムを構成するのは、作業に必要なすべてのスキルや専門知識をグループ全体として備える人たちである。また、必要に応じてそうしたスキルを共有または習得できる人たちである。
スクラムでは、検査と適応のための 4 つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。これらのイベントが機能するのは、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現しているからである。
3.1 透明性
創発的なプロセスや作業は、作業を実行する人とその作業を受け取る人に見える必要がある。スクラムにおける重要な意思決定は、 3つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを高める意思決定につながる可能性がある。
透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。
3.2 検査
スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱心に検査されなければならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、検査を支援するために、 5 つのイベントでリズムを提供している。
検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。
3.3 適応
プロセスのいずれかの側面が許容範囲を逸脱していたり、成果となるプロダクトが受け入れられなかったりしたときは、適用しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最小限に抑えるため、できるだけ早く調整しなければならない。
関係者に権限が与えられていないときや、自己管理されていないときは、適応が難しくなる。スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。
4. スクラムの価値基準
スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。
確約（ Commitment ）
集中（ Focus ）
公開（ Openness ）
尊敬（ Respect ）
勇気（ Courage ）
スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する。スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。スクラムチームとステークホルダーは、作業や課題を公開する。スクラムチームのメンバーは、お互いに能力のある独立した個人として尊敬し、一緒に働く人たちからも同じように尊敬される。スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ。
これらの価値基準は、スクラムチームの作業・行動・振る舞いの方向性を示している。下される意思決定、実行される手順、スクラムの使用方法は、これらの価値基準を減少や弱体化させるものではなく、強化させるものでなければならない。スクラムチームのメンバーは、スクラムのイベントや作成物を用いながら、これらの価値基準を学習および探求する。これらの価値基準がスクラムチームや一緒に働く人たちによって具現化されるとき、経験主義のスクラムの三本柱「透明性」「検査」「適応」に息が吹き込まれ、信頼が構築される。
5. スクラムチーム
スクラムの基本単位は、スクラムチームという小さなチームである。スクラムチームは、スクラムマスター 1 人、プロダクトオーナー 1 人、複数人の開発者で構成される。スクラムチーム内には、サブチームや階層は存在しない。これは、一度にひとつの目的（プロダクトゴール）に集中している専門家が集まった単位である。
スクラムチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている。また、自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。
スクラムチームは、敏捷性を維持するための十分な小ささと、スプリント内で重要な作業を完了するための十分な大きさがあり、通常は 10 人以下である。一般的に小さなチームのほうがコミュニケーションがうまく、生産性が高いことがわかっている。スクラムチームが大きくなりすぎる場合は、同じプロダクトに専念した、複数のまとまりのあるスクラムチームに再編成することを検討する必要がある。したがって、同じプロダクトゴール、プロダクトバックログ、およびプロダクトオーナーを共有する必要がある。
スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。スクラムチームは、自分たちで作業を管理できるように組織によって構成され、その権限が与えられている。持続可能なペースでスプリントの作業を行うことにより、スクラムチームの集中と一貫性が向上する。
スクラムチーム全体が、スプリントごとに価値のある有用なインクリメントを作成する責任を持つ。スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスターという 3 つの明確な責任を定義する。
5.1 開発者
開発者はスクラムチームの一員である。各スプリントにおいて、利用可能なインクリメントのあらゆる側面を作成することを確約する。
開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。ただし、開発者は常に次の結果に責任を持つ。
- スプリントの計画（スプリントバックログ）を作成する。
- 完成の定義を忠実に守ることにより品質を作り込む。
- スプリントゴールに向けて毎日計画を適応させる。
- 専門家としてお互いに責任を持つ。
5.2 プロダクトオーナー
プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、
- プロダクトゴールを策定し、明示的に伝える。
- プロダクトバックログアイテムを作成し、明確に伝える。
- プロダクトバックログアイテムを並び替える。
- プロダクトバックログに透明性があり、見える化され、理解されるようにする。
上記の作業は、プロダクトオーナーが行うこともできるが、他の人に委任することもできる。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。
プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレビューでの検査可能なインクリメントによって見える化される。
プロダクトオーナーは 1 人の人間であり、委員会ではない。プロダクトオーナーは、多くのステークホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。
5.3 スクラムマスター
スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう支援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。
スクラムマスターは、さまざまな形でスクラムチームを支援する。
- 自己管理型で機能横断型のチームメンバーをコーチする。
- スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できるよう支援する。
- スクラムチームの進捗を妨げる障害物を排除するように働きかける。
- すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする。
スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。
- 効果的なプロダクトゴールの定義とプロダクトバックログ管理の方法を探すことを支援する。
- 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
- 複雑な環境での経験的なプロダクト計画の策定を支援する。
- 必要に応じてステークホルダーとのコラボレーションを促進する。
スクラムマスターは、さまざまな形で組織を支援する。
- 組織へのスクラムの導入を指導・トレーニング・コーチする。
- 組織においてスクラムの実施方法を計画・助言する。
- 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。
- ステークホルダーとスクラムチームの間の障壁を取り除く。
6. スクラムイベント
スプリントは他のすべてのイベントの入れ物である。スクラムにおけるそれぞれのイベントは、スクラムの作成物の検査と適応をするための公式の機会である。これらのイベントは必要な透明性を実現するために明確に設計されている。規定通りにイベントを運用しなければ、検査と適応の機会が失われる。スクラムにおけるイベントは、規則性を生み、スクラムで定義されていない会議の必要性を最小限に抑えるために用いられる。
すべてのイベントは、複雑さを低減するために、同じ時間と場所で開催されることが望ましい。
6.1 スプリント
スプリントはスクラムにおける心臓の鼓動であり、スプリントにおいてアイデアが価値に変わる。
一貫性を保つため、スプリントは 1 か月以内の決まった⻑さとする。前のスプリントが終わり次第、新しいスプリントが始まる。
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で行われる。
スプリントでは、
- スプリントゴールの達成を危険にさらすような変更はしない。
- 品質を低下させない。
- プロダクトバックログを必要に応じてリファインメントする。
- 学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要になる場合がある。
スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か月ごとに確実になり、予測可能性が高まる。スプリントの期間が⻑すぎると、スプリントゴールが役に立たなくなり、複雑さが増し、リスクが高まる可能性がある。スプリントの期間を短くすれば、より多くの学習サイクルを生み出し、コストや労力のリスクを短い時間枠に収めることができる。スプリントは短いプロジェクトと考えることもできる。
進捗の見通しを立てるために、バーンダウン、バーンアップ、累積フローなど、さまざまなプラクティスが存在する。これらの有用性は証明されているが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに発生したことだけが、将来を見据えた意思決定に使用できる。
スプリントゴールがもはや役に立たなくなった場合、スプリントは中止されることになるだろう。プロダクトオーナーだけがスプリントを中止する権限を持つ。
6.2 スプリントプランニング
スプリントプランニングはスプリントの起点であり、ここではスプリントで実行する作業の計画を立てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の人をスプリントプランニングに招待してもよい。
スプリントプランニングは次のトピックに対応する：
トピック 1 ：このスプリントはなぜ価値があるのか？
プロダクトオーナーは、プロダクトの価値と有用性を今回のスプリントでどのように高めることができるかを提案する。次に、スクラムチーム全体が協力して、そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。スプリントゴールは、スプリントプランニングの終了までに確定する必要がある。
トピック 2 ：このスプリントで何ができるのか？
開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。それによって、チームの理解と自信が高まる。
スプリント内でどれくらい完了できるかを選択するのは難しいかもしれない。しかしながら、開発者が過去の自分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めていけば、スプリントの予測に自信が持てるようになる。
トピック 3 ：選択した作業をどのように成し遂げるのか？
開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメントを作成するために必要な作業を計画する。これは多くの場合、プロダクトバックログアイテムを 1 日以内の小さな作業アイテムに分解することによって行われる。これをどのように行うかは、開発者だけの裁量とする。プロダクトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてくれない。
スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれらを提供するための計画をまとめてスプリントバックログと呼ぶ。
スプリントが 1 か月の場合、スプリントプランニングのタイムボックスは最大で 8 時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。
6.3 デイリースクラム
デイリースクラムの目的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。
デイリースクラムは、スクラムチームの開発者のための 15 分のイベントである。複雑さを低減するために、スプリント期間中は毎日、同じ時間・場所で開催する。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。
開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの 1 日の作業の実行可能な計画を作成する限り、必要な構造とやり方を選択できる。これは集中を生み出し、自己管理を促進する。
デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする。
開発者が計画を調整できるのは、デイリースクラムのときだけではない。スプリントの残りの作業を適応または再計画することについて、より詳細な議論をするために、開発者は一日を通じて頻繁に話し合う。
6.4 スプリントレビュー
スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う。
スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビューする。この情報に基づいて、参加者は次にやるべきことに協力して取り組む。新たな機会に見合うようにプロダクトバックログを調整することもある。スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする。
スプリントレビューは、スプリントの最後から 2 番目のイベントであり、スプリントが 1 か月の場合、タイムボックスは最大 4 時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。
6.5 スプリントレトロスペクティブ
スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。
スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発生したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。
スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加することもできる。
スプリントレトロスペクティブをもってスプリントは終了する。スプリントが 1 か月の場合、スプリントレトロスペクティブは最大 3 時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。
7. スクラムの作成物
スクラムの作成物は、作業や価値を表している。これらは重要な情報の透明性を最大化できるように設計されている。作成物を検査する人が、適応するときと同じ基準を持っている。各作成物には、透明性と集中を高める情報を提供する「確約（コミットメント）」が含まれている。これにより進捗を測定できる。
- プロダクトバックログのためのプロダクトゴール
- スプリントバックログのためのスプリントゴール
- インクリメントのための完成の定義
これらの確約は、スクラムチームとステークホルダーの経験主義とスクラムの価値基準を強化するために存在する。
7.1 プロダクトバックログ
プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧である。これは、スクラムチームが行う作業の唯一の情報源である。
1 スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。
作業を行う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を支援することもできる。
7.1.1 確約（コミットメント）：プロダクトゴール
プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。
プロダクトとは価値を提供する手段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。
プロダクトゴールは、スクラムチームの⻑期的な目標である。次の目標に移る前に、スクラムチームはひとつの目標を達成（または放棄）しなければならない。
7.2 スプリントバックログ
スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実行可能な計画（どのように）で構成される。
スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで行う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。
7.2.1 確約（コミットメント）：スプリントゴール
スプリントゴールはスプリントの唯一の目的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。スプリントゴールはまた、一貫性と集中を生み出し、スクラムチームに一致団結した作業を促すものでもある。
スプリントゴールは、スプリントプランニングで作成され、スプリントバックログに追加される。開発者がスプリントで作業するときには、スプリントゴールを念頭に置く。作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。
7.3 インクリメント
インクリメントは、プロダクトゴールに向けた具体的な踏み石である。インクリメントはこれまでのすべてのインクリメントに追加する。また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。価値を提供するには、インクリメントを利用可能にしなければならない。
スプリントでは、複数のインクリメントを作成可能である。インクリメントをまとめたものをスプリントレビューで提示する。それによって、経験主義がサポートされる。ただし、スプリント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。スプリントレビューのことを価値をリリースするための関門と見なすべきではない。
完成の定義を満たさない限り、作業をインクリメントの一部と見なすことはできない。
7.3.1 確約（コミットメント）：完成の定義
完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。
プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する。
完成の定義により、作業が完了してインクリメントの一部となったことが全員の共通認識となり、透明性が生み出される。プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。ましてやスプリントレビューで提示することもできない。そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。
インクリメントの完成の定義が組織の標準の一部となっている場合、すべてのスクラムチームは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必要がある。
開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場合、共通の完成の定義を作成して、それに準拠する必要がある。
8. 最後に
スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてを備えたものがスクラムであり、その他の技法・方法論・プラクティスの入れ物として機能するものである。
8.1 謝辞
8.1.1 人々
スクラムに貢献してくれた多くの方々の中でも、最初に尽力してくれた人物の名前を挙げたい。まず、Jeff Sutherlandと一緒に働いたJeff McKennaとJohn Scumniotales。それから、Ken Schwaberと一緒に働いたMike SmithとChris Martin。みんなで一緒に働いたこともあった。その後の数年間は、さらに多くの方々が貢献してくれた。彼らの助けがなければ、スクラムは今日のように洗練されていなかっただろう。
8.1.2 スクラムガイドの歴史
Ken SchwaberとJeff Sutherlandが、 1995 年のOOPSLAカンファレンスにおいてスクラムを共同発表した。この発表は、KenとJeffが過去数年間で学んだことを文書化したものであり、はじめて公開された正式なスクラムの定義である。
スクラムガイドは、Jeff SutherlandとKen Schwaberが 30 年以上かけて開発・進化・保守しているスクラムを文書化したものである。その他の情報源では、スクラムフレームワークを補完するパターン、プロセス、インサイトなどが提供されている。これらは、生産性・価値・創造性・結果に対する満足度を高める可能性がある。
スクラムの詳細な歴史については、別のところで説明されている。初期の試行錯誤および証明の場であるIndividual, Inc.、Newspage、Fidelity Investments、IDX（現GE Medical）の各社に感謝したい。
9. 翻訳について
本ガイドは、上記の開発者による英語バージョンを日本語に翻訳したものである。日本語訳は角征典、荒本実、和田圭介が担当した。
過去の版の翻訳レビューについては、守田憲司さん、高江洲睦さん、永瀬美穂さん、栗秋宏徳さん、川口恭伸さん、角谷信太郎さん、木村卓央さん、原田騎郎さん、吉羽龍太郎さん、むらはしけんいちさん、いろさん、たなべすなおさんに協力いただいた。
翻訳に関する連絡先：角征典（kdmsnr@gmail.com）
10. 用語集
Genera Terms* 一般用語
Scrum スクラム
Theory 理論
Empiricism 経験主義
Transparency 透明性
Inspection 検査
Adaptation 適応
Events イベント
Sprint スプリント
Sprint Planning スプリントプランニング
Daily Scrum デイリースクラム
Sprint Review スプリントレビュー
Sprint Retrospective スプリントレトロスペクティブ
Roles 役割
Scrum Team スクラムチーム
Scrum Master スクラムマスター
Product Owner プロダクトオーナー
Developers 開発者
Artifacts 作成物
Product Backlog プロダクトバックログ
Sprint Backlog スプリントバックログ
Increment インクリメント
Misc その他
Definition of Done 完成の定義
11. スクラムガイド 2017 年版からスクラムガイド 2020 年版への変更点
11.1 指示的な部分を削減
スクラムガイドは時間が経つにつれて少し指示的なものになっていた。 2020 年版では、指示的な表現を削除または緩和して、スクラムを最小限かつ十分なフレームワークに戻すことを目的としている。たとえば、デイリースクラムの質問の削除、PBI（プロダクトバックログアイテム）の属性に関する記述の緩和、スプリントバックログにあるレトロスペクティブのアイテムに関する記述の緩和、スプリントの中止のセクションの削減などを実施した。
11.2 ひとつのチームがひとつのプロダクトに集中する
これはチーム内で分断が発生し、POと開発チームの関係が「プロキシ」や「我々と彼ら」といった問題につながることを排除するためである。存在するのは、PO、SM、開発者の 3 つの異なる責任を持ち、同じ目的を共有するひとつの「スクラムチーム」だけである。
11.3 プロダクトゴールの導入
スクラムガイド 2020 年版では「プロダクトゴール」を導入した。スクラムチームに大きな価値のある目的に集中してもらうためである。各スプリントでは、プロダクトを全体的なプロダクトゴールに近づける必要がある。
11.4 スプリントゴール、完成の定義、プロダクトゴールの居場所
以前のスクラムガイドでは、明確なアイデンティティーを与えることなく、「スプリントゴール」と「完成の定義」について説明していた。これらは作成物ではなく、作成物に付随するものだった。 2020 年版では「プロダクトゴール」を導入し、これらの位置づけを明確にした。 3つの作成物には、それぞれの「確約（コミットメント）」が含まれる。つまり、プロダクトバックログにはプロダクトゴール、スプリントバックログにはスプリントゴール、インクリメントには完成の定義（カッコをなくした）が含まれる。これらの存在により透明性がもたらされ、作成物の進捗に集中できるようになる。
11.5 自己組織化よりも自己管理
以前のスクラムガイドでは、開発チームは自己組織化しており、「誰が」「どのように」作業するかを選択できるとしていた。 2020 年版ではスクラムチームの自己管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できるようにした。
11.6 スプリントプランニングの 3 つのトピック
これまでのスプリントプランニングのトピックである「What」と「How」に加えて、スクラムガイド 2020 年版では、 3 つ目のトピック「Why」に重点を置いた。これはスプリントゴールで言及されている。
11.7 幅広い読者のために全体的に文章を簡略化
スクラムガイド 2020 年版では、冗⻑で複雑な文章とITに関する記述（例：テスト、システム、設計、要求など）を排除している。以上の変更で、スクラムガイドは 13 ページ未満となった。