スクラムガイド｜2020 全文変更点解説

Agenda

1. スクラム公式ガイド（ゲームのルール）
2. スクラムガイドに対する個人的な感想
3. スクラムガイドの目的 | Purpose of the Scrum Guide
4. スクラムの定義 | Scrum Definition
5. スクラムの理論 | Scrum Theory
6. スクラムの価値基準 | Scrum Values
7. スクラムチーム | Scrum Team
8. スクラムイベント | Scrum Events
9. スプリント | The Sprint
10. スプリントプランニング | Sprint Planning
11. デイリースクラム | Daily Scrum
12. スプリントレビュー | Sprint Review
13. スプリントレトロスペクティブ | Sprint Retrospective
14. スクラムの作成物 | Scrum Artifacts
15. プロダクトバックログ | Product Backlog
16. スプリントバックログ | Sprint Backlog
17. インクリメント | Increment
18. 最後に | End Note
19. スクラムガイド2017年版からスクラムガイド2020年版への変更点
20. 長文お疲れさまでした
21. スクラムとソフトウェア開発
22. SCRUMMASTER THE BOOK

スクラム公式ガイド（ゲームのルール）

スクラムはスクラムガイドにて定義されています。

スクラムガイドはスクラムとしての公式な見解となっておりますので、実践する人、関係する人は必ず目を通し、理解したいところです。これまでに多くの実践者の失敗や成功による知恵が詰まっておりますので、必ずや道標となりえます。

ただ、あくまでガイドです。この通りにやればうまくいくものでもなく、これに従わなければいけないかというとそうでもありません。そのため、このガイドから少し異なっているからといって目くじらを立てて「スクラム警察」のように振る舞ってしまうのは逆に害となってしまう可能性があります。

もし、あなたがスクラムに価値があると思うのであれば、まずはこれに沿ってやってみよう、という気持ちで取り組んでみてください。

これは、「守破離」における「守」であると捉えています。

※「守」を飛ばして「破」や「離」に進もうとするとワケがわからなくなり、勝手にスクラムはダメだと判断する結果となる可能性がありますのでお気をつけください。

この最小公約数的なスクラムガイドのルールの一部を改変したり、なくしたりすると、スクラムによる本来の価値を享受できなくなるようです。

現場に合わせて改変してはいけない、ということではありませんが、改変したことで本質から外れてしまうと、それは「スクラムとは呼べない」ということになります。

ですが、スクラムから取り入れたものが一部であっても、良い効果を享受できているのであればそれでいいんだと思います。カイゼンし続けることがアジャイルだと思います。

加えて、スクラムガイドは数年に一回更新されることがとても良いです。蓄積した学習を共有したり、世の中に合わせて適合していくことはそれ自体もアジャイルかと思います。

一方で、アジャイルソフトウェア開発宣言は一度も更新されないため、内容の一部が古くなってしまっています。

※例えば、「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」という文がアジャイル宣言の背後にある原則に記されていますが、現代ではもっと短い間隔でリリースすることも容易になっています。

もしかすると、みなさんが良かれと思って独自に試したり解釈していることが、数年後の新しいスクラムガイドに載ったりするかもしれませんね。

さて、スクラムガイドもアジャイルソフトウェア開発宣言と同じように、経験のない人が読んで理解することは難しい内容となっています。そのため、読んでもピンとこない人向けに、私の解釈にて解説を綴ります。

ちなみにスクラムガイドは下記のWebサイトに多言語でHTML/PDF版があります。

Home | Scrum Guides

Scrum is a framework for developing and sustaining complex products. The Scrum Guide contains th ...

https://www.scrumguides.org/

スクラムガイドに対する個人的な感想

スクラムガイドは定期的に更新しつづけられ、スリムになっていることはとても好感が持てます。スクラムガイド自体にMVP（実用最小限の製品：Minimum Viable Product）を感じます。ソフトウェア開発の現場だけでなく、関係する組織やマネージャーなど広く多くの人に読んでもらいたい内容となっています。

スクラムやアジャイルについてよくわからない、という前に、まずはスクラムガイドをしっかりと読みましょう。話しはそれからです。

きっと、多くの気づきがあります。スクラムガイドは削ぎ落とされたフレームワークですが、それでもこの通りに実践できているチームはそう多くはないように思います。

その気づき、自分のチームとの差分から、できる限り近づいていけるといいですね。

感想：★★★★★

スクラムガイドに沿ってないスクラム風なことを「なんちゃってスクラム」「ニセスクラム」「野良スクラム」などと呼ばれることもあります。

ただ、これはあくまで守破離の「守」と理解しておりますので、完全体のスクラムを目指したあとは、その現場現場でさらにアジャイルな状態になるべく探求をしてもらえると幸いです。

ちなみに、スクラムはソフトウェア業界以外にも適用されているようで、スクラムガイドも汎用的な内容になってきています。そのため、ソフトウェア開発をしている人には過去のスクラムガイドに具体的に記載されている内容の方がピンときやすいものもあるかもしれません。

スクラムガイドの英語版は13ページですが、
日本語版でも18ページしかないのでサクッと読めます😀

あとひとつだけ加えるとすると、スクラムをやることが目的とならないように気をつけてください。あなたの組織やチームで実現したいこと、ビジョン、ミッション、ゴールなどがあるはずです。

それを達成していくためにスクラムが有効となりえるなら積極的に導入していきましょう！

スクラムはとてもうまくまわるようになったが、組織やチームのゴールに近付いていない、という状況は本末転倒です。

ここからはスクラムガイドの全文を引用しながら解説いたします。

スクラムガイドの目的 | Purpose of the Scrum Guide

我々は 1990 年代初頭にスクラムを開発した。世界中の人たちがスクラムを理解できるように、スクラムガイドの最初のバージョンを 2010 年に執筆した。それ以来、機能的に小さな更新を加えながらスクラムガイドを進化させてきた。我々は共にスクラムガイドを支援している。
スクラムガイドにはスクラムの定義が含まれている。フレームワークの各要素には特定の目的があり、スクラムで実現される全体的な価値や結果に欠かせないものとなっている。スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。場合によっては、スクラムが役に立たなくなることさえある。
成長を続ける複雑な世界において、スクラムの利用は増加しており、我々はそれを見守っている。スクラムが誕生したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採用されている。そうした状況を見ると、我々も光栄である。スクラムが広まったことにより、開発者、研究者、アナリスト、科学者、その他の専門家もスクラムを利用するようになった。スクラムでは「開発者」という言葉を使っているが、開発者以外を排除しているのではなく、単純化のために使用しているだけである。スクラムから価値を得ているのであれば、そこにあなたも含まれていると考えてもらいたい。
スクラムを利用していると、本文書で説明しているスクラムフレームワークと適合するようなパターン、プロセス、インサイトを発見・適用・考案することもあるだろう。そうしたものについては、スクラムガイドの目的の範囲外である。これらは状況に依存しており、スクラムを利用する状況によって大きく異なるからだ。スクラムフレームワークで利用できる戦術にはさまざまなものが存在するが、それらはスクラムガイド以外のところで説明されている。
Ken Schwaber & Jeff Sutherland 2020 年 11 月
スクラムガイド（2020）

スクラムガイドを執筆されているのはKen Schwaber と Jeff Sutherland のお二人でアジャイルソフトウェア開発宣言に署名されています。ただ、スクラムガイドの改訂は様々なスクラムの実践者やコミュニティからも情報を得ているようです。

スクラムのルールに従わないとスクラムが役に立たなくなることがあると明記されていますね。表紙にもサブタイトルで「ゲームのルール」とあります。どんなゲームでもルールを守らないと成立しません。

「なんちゃってアジャイル」とか「ニセスクラム」と呼ばれたとしても、以前よりもカイゼンし続ける状態になっているのであれば、それはもうアジャイルであると思います。

そう、スクラムはあくまでフレームワークで骨組みであるため、中身がありません。中身は私たちで埋めていく必要があります。

スクラムは情報などを見える化はしてくれますが、それをどのように解決していけば良いかはほとんど書かれていません。

つまり、空っぽのスクラムを実践するためには、その中身を詰めるものを選んで取り入れないと成り立たないのです。

スクラムの定義 | Scrum Definition

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。
簡単に言えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。
1. プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。
2. スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。
3. スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。
4. 繰り返す。
スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を生み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する人たちの集合知で構築されている。スクラムのルールは詳細な指示を提供するものではなく、実践者の関係性や相互作用をガイドするものである。
スクラムフレームワークの中で、さまざまなプロセス、技法、手法を使用できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。
スクラムガイド（2020）

スクラムはシンプルだから、まずはそのまま試して価値を生み出すのか判断して欲しい、とあります。

もちろん、スクラムが適している場合とそうではない場合がありますし、スクラムは手段のひとつですので誰も押し付けているわけではありません。ただ、中途半端なスクラムでスクラムを判断することはしないでくださいね、と読み取れます。

スクラムで可視化されて改善が可能になるというのは実践している身としてはよくわかります。まず透明性があって、それがあることで検査と適応があります。人によってはスクラムを「情報を把握するフレームワーク」と説明することもあります。

スクラムの理論 | Scrum Theory

スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から生まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。
スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採用している。スクラムを構成するのは、作業に必要なすべてのスキルと経験をグループ全体として備える人たちである。また、必要に応じてそうしたスキルを共有または習得できる人たちである。
スクラムでは、検査と適応のための 4 つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。これらのイベントが機能するのは、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現しているからである。
スクラムガイド（2020）

スクラムは色々な文脈から生まれていますが、ここでは明確に「経験主義（Empiricism）」と「リーン思考（Lean Thinking）」に基づいていると謳われています。

経験主義の反対は仮説だけに基づいて進めること、もっと言うと「思い込みのママ」進めてしまうことです。どこかの誰かがこうだろうと思った、言った、書いたことをベースとしてしまい、それが正しいのか？という検証をせずに進めてしまい、モノを作ってから実は間違っていた、やっぱり間違っていたね、となりがちです。

一方の経験主義は経験したリアルなものから学習し、学習したものを観察して、洞察を得ながら意思決定をしていくため、正解の確率がぐっと高まります。スクラムは分からないことと分からないことを増やし続ける学習の探求とも言えると考えています。

イテレーティブでインクリメンタルという言葉はピンと来ますでしょうか。日本語訳の反復的で漸進的としても、特に漸進的という言葉を普段使っている人は稀でしょう。

平易な言葉で言い換えるとすると「少しづつ繰り返しながら大きくしていく」です。

透明性 | Transparency

創発的なプロセスや作業は、作業を実行する人とその作業を受け取る人に見える必要がある。スクラムにおける重要な意思決定は、3 つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを高める意思決定につながる可能性がある。透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。
スクラムガイド（2020）

スクラムの三本柱の中で最も重要で最も難しいのが「透明性」と言われています。

「透明性」とは第三者にもはっきりとわかるようにすることです。

何をしようとしているのか、何をしているのか、何を作っているのかについて、まずは自分たちでわかるようにすることです。その上で、それらをなんら加工せずに第三者が見てすぐに分かるような状態にしていることが、透明性が高い、となります。

組織の中にいると不都合なことを隠すという文化のところも多いかと思います。それを可視化して透明化することが難しいことは理解しやすいと思います。

検査 | Inspection

スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱心に検査されなければならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、検査を支援するために、5 つのイベントでリズムを提供している。検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。
スクラムガイド（2020）

5つのイベントで検査のタイミングが用意されているため、定期的に検査することができます。

適応のない検査は意味がないとありますが、透明性→検査→適応のサイクルを回し続けることが重要です。

ちなみに検査は望ましい姿と現実との差分であるため、まずは望ましい姿やゴールを定義したり、チームで共有することが先に必要となります。

適応 | Adaptation

プロセスのいずれかの側面が許容範囲を逸脱していたり、成果となるプロダクトが受け入れられなかったりしたときは、適用しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最小限に抑えるため、できるだけ早く調整しなければならない。関係者に権限が与えられていないときや、自己管理されていないときは、適応が難しくなる。スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。
スクラムガイド（2020）

不確実性のあるプロダクト開発を進めていれば、当然、計画の許容範囲を逸脱することがあるでしょう。

透明性があれば定期的に検査することで許容範囲か否かの判断ができ、逸脱していればすぐに適応してまた許容範囲内にすることが求められます。そうして、リスクをためずに軽減させながら開発することができます。

「瞬間に適応」するためには、スクラムチーム内で素早く意思決定していく必要があるため、意思決定ができる権限と自己管理の能力を持つことが求められます。

問題に気づいたり、このままではうまくいかないだろうと気づいても、誰かがなんとかしてくれるだろう、と思って何もアクションを起こしていないとすると、適応とはほど遠い状態にあると言えます。

スクラムの価値基準 | Scrum Values

スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。
確約（Commitment）、
集中（Focus）、
公開（Openness）、
尊敬（Respect）、
勇気（Courage）
スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する。スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。スクラムチームとステークホルダーは、作業や課題を公開する。スクラムチームのメンバーは、お互いに能力のある独立した個人として尊敬し、一緒に働く人たちからも同じように尊敬される。スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ。
これらの価値基準は、スクラムチームの作業・行動・振る舞いの方向性を示している。下される意思決定、実行される手順、スクラムの使用方法は、これらの価値基準を減少や弱体化させるものではなく、強化させるものでなければならない。スクラムチームのメンバーは、スクラムのイベントや作成物を用いながら、これらの価値基準を学習および探求する。これらの価値基準がスクラムチームや一緒に働く人たちによって具現化されるとき、経験主義のスクラムの三本柱「透明性」「検査」「適応」に息が吹き込まれ、信頼が構築される。
スクラムガイド（2020）

スクラムの価値基準はとても重要なのですが、なぜかスクラムを説明する際によく省略されます。

しかし、この価値基準をスクラムチームが持っていないと、スクラムの良さが効果的に発揮されません。ただイベントをこなしてスプリント単位に開発しても、透明性・検査・適応がうまく回らないでしょう。

確約

ここでは最大限の努力をすることを確約するという意味で、守れなかったら怒られる、罰を受けるといった類ではありません。

具体的には開発者、プロダクトオーナー、スクラムマスターというロールに期待されていることを全うできるよう努力するということだと解釈しています。

これがないと、他の業務との掛け持ちをしたり、各種イベントへの出席率が低下したり、スプリントバックログをインクリメントに変えられないものが増える、など多くの弊害が発生するでしょう。

集中

これは生産性を高めるために集中する、と解釈しています。

例えば、仕掛かり作業を減らして優先順位の高い作業から順次取り組むことや、タイムボックスをきって集中力を高める、などがあります。

ひとは複数同時平行で作業をしたり、1日の中で色々な作業をしようとすると頭を切り替えるムダが発生してします。このあたりはリーンの文脈も含まれているかと思います。

公開

公開がないと透明性はほど遠くなります。

アジャイルやスクラムでは良いことも悪いことも公開しますし、気づきにくいことを目にみえるようにします。

それによって事実を正しく捉えて、正しく判断できるようになります。

逆に、特に悪い情報を隠蔽してしまうと誤った判断をすることになります。

尊敬

尊敬の範囲は広く、スクラムチーム内のメンバーやステークホルダー、組織の内外の人も含まれます。

尊敬の心を持つことで、役職や立場に関係なく、多くの人から学びを得られたり、助けを得られたりするでしょう。（私は、人生みな師と思っています。）

人を尊重するこころも一緒に持つと良いでしょう。

勇気

勇気とは正しいことをする勇気です。

めんどうくさい、怒られるかもしれない、失敗するかもしれない、貧乏くじをひくかもしれない、もっと大変になる、などの後ろ向きな理由でアクションを起こせないことがよくあると思います。

勇気を持つことで一時的には大変かもしれませんが、中長期的だったり本質的に正しいことに向かうことができます。

ただ、勇気と無謀も表裏一体的なところがあります。勇気を出すための下準備も合わせてできるとよいと思います。例えば、心理的安全性を高めることによって人前で意見を言う勇気が出せるようになったり、しっかりとしたテストコードを書くことによってリファクタリングをする勇気が出るでしょう。

怖がっている人にただ勇気を出せといっても事故を起こすだけなので注意しましょう。段階が大事です。

スクラムチーム | Scrum Team

スクラムの基本単位は、スクラムチームという小さなチームである。スクラムチームは、スクラムマスター1 人、プロダクトオーナー1 人、複数人の開発者で構成される。スクラムチーム内には、サブチームや階層は存在しない。これは、一度にひとつの目的（プロダクトゴール）に集中している専門家が集まった単位である。
スクラムチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている。また、自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。
スクラムチームは、敏捷性を維持するための十分な小ささと、スプリント内で重要な作業を完了するための十分な大きさがあり、通常は 10 人以下である。一般的に小さなチームのほうがコミュニケーションがうまく、生産性が高いことがわかっている。スクラムチームが大きくなりすぎる場合は、同じプロダクトに専念した、複数のまとまりのあるスクラムチームに再編成することを検討する必要がある。したがって、同じプロダクトゴール、プロダクトバックログ、およびプロダクトオーナーを共有する必要がある。
スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。スクラムチームは、自分たちで作業を管理できるように組織によって構成され、その権限が与えられている。持続可能なペースでスプリントの作業を行うことにより、スクラムチームの集中と一貫性が向上する。
スクラムチーム全体が、スプリントごとに価値のある有用なインクリメントを作成する責任を持つ。スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスターという 3つの明確な責任を定義する。
スクラムガイド（2020）

「チーム（Team）」というのはアジャイルやスクラムにおいて非常に重要な概念です。「グループ」に共通の目標や目的が共有されると「チーム」になります。さらに「自己管理型（旧来では自己組織化だった）」というのはかなり成熟したチームと言えます。

役割はそれぞれありますが、全ての問題はチームに帰属すると捉えることで高い生産性を発揮することができます。一方で、

開発者 | Developers

開発者はスクラムチームの一員である。各スプリントにおいて、利用可能なインクリメントのあらゆる側面を作成することを確約する。開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。ただし、開発者は常に次の結果に責任を持つ。
　・スプリントの計画（スプリントバックログ）を作成する。
　・完成の定義を忠実に守ることにより品質を作り込む。
　・スプリントゴールに向けて毎日計画を適応させる。
　・専門家としてお互いに責任を持つ。
スクラムガイド（2020）

“開発者"という表現は少々誤解を生みやすいものとなっています。

スクラムではデザイナーやアーキテクト、テスターと呼ばれるような人も開発者というロールに含まれます。

また、"品質を作り込む"とあります。アジャイルは品質が悪いと言われることがありますが、むしろ、スプリント単位に品質を作り込む必要があるため、より品質に対して厳しいと言えます。

プロダクトオーナー | Product Owner

プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、
　・プロダクトゴールを策定し、明示的に伝える。
　・プロダクトバックログアイテムを作成し、明確に伝える。
　・プロダクトバックログアイテムを並び替える。
　・プロダクトバックログに透明性があり、見える化され、理解されるようにする。
上記の作業は、プロダクトオーナーが行うこともできるが、他の人に委任することもできる。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレビューでの検査可能なインクリメントによって見える化される。プロダクトオーナーは 1人の人間であり、委員会ではない。プロダクトオーナーは、多くのステークホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。
スクラムガイド（2020）

スクラムはプロダクトオーナーに厳しいフレームワークだと言われることがあります。それは、役割が多く重要である上に1人の設置しか許されていないところにあります。しかし、上記を参照すると「プロダクトオーナーが行うこともできるが、他の人に委任することもできる」とあります。実は、プロダクトオーナーが全てをやらないといけないわけではないのです。

このあたりはよくある誤解です。プロダクトオーナーが一人でプロダクトバックログを作成したり、管理したりすることは現実的ではありません。ただでさえ忙しいプロダクトオーナーがボトルネックになってしまいます。

スクラムマスター | Scrum Master

スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラティクスを全員に理解してもらえるよう支援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。スクラムマスターは、さまざまな形でスクラムチームを支援する。
　・自己管理型で機能横断型のチームメンバーをコーチする。
　・スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できるよう支援する。
　・スクラムチームの進捗を妨げる障害物を排除するように働きかける。
　・すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする。
スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。
　・効果的なプロダクトゴールの定義とプロダクトバックログ管理の方法を探すことを支援する。
　・明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
　・複雑な環境での経験的なプロダクト計画の策定を支援する。
　・必要に応じてステークホルダーとのコラボレーションを促進する。
スクラムマスターは、さまざまな形で組織を支援する。
　・組織へのスクラムの導入を指導・トレーニング・コーチする。
　・組織においてスクラムの実施方法を計画・助言する。
　・複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。
　・ステークホルダーとスクラムチームの間の障壁を取り除く。
スクラムガイド（2020）

スクラムマスターは開発者とプロダクトオーナーと組織の支援をしないといけませんので大変です。スクラムチームのファシリテーションをするイメージは多くの人にあると思いますが、組織の支援をするためにはアジャイルやスクラムに相当精通していないとできないでしょう。

また、「スクラムマスター」というひびきはかっこいいですが、実はかなり泥臭いです。

スクラムイベント | Scrum Events

スプリントは他のすべてのイベントの入れ物である。スクラムにおけるそれぞれのイベントは、スクラムの作成物の検査と適応をするための公式の機会である。これらのイベントは必要な透明性を実現するために明確に設計されている。規定通りにイベントを運用しなければ、検査と適応の機会が失われる。スクラムにおけるイベントは、規則性を生み、スクラムで定義されていない会議の必要性を最小限に抑えるために用いられる。すべてのイベントは、複雑さを低減するために、同じ時間と場所で開催されることが望ましい。
スクラムガイド（2020）

スクラムの公式なイベントにはそれぞれに目的があり、全てが組み合わされることによって、スクラムが効果的に力を発揮するように作られています。特に、透明性、検査、適応が複数のイベントを通して維持できているかが重要です。そのため、スプリントレビューやレトロスペクティブを省略してしまったり、デイリースクラムが形骸化してしまうことがないようにしましょう。

スプリント | The Sprint

スプリントはスクラムにおける心臓の鼓動であり、スプリントにおいてアイデアが価値に変わる。
一貫性を保つため、スプリントは 1 か月以内の決まった長さとする。前のスプリントが終わり次第、新しいスプリントが始まる。
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で行われる。スプリントでは、
　・スプリントゴールの達成を危険にさらすような変更はしない。
　・品質を低下させない。
　・プロダクトバックログを必要に応じてリファインメントする。
　・学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要になる場合がある。
スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か月ごとに確実になり、予測可能性が高まる。スプリントの期間が長すぎると、スプリントゴールが役に立たなくなり、複雑さが増し、リスクが高まる可能性がある。スプリントの期間を短くすれば、より多くの学習サイクルを生み出し、コストや労力のリスクを短い時間枠に収めることができる。スプリントは短いプロジェクトと考えることもできる。
進捗の見通しを立てるために、バーンダウン、バーンアップ、累積フローなど、さまざまなプラクティスが存在する。これらの有用性は証明されているが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに発生したことだけが、将来を見据えた意思決定に使用できる。
スプリントゴールがもはや役に立たなくなった場合、スプリントは中止されることになるだろう。プロダクトオーナーだけがスプリントを中止する権限を持つ。
スクラムガイド（2020）

アイデアが価値に変わるというのは、ここではスプリントバックログをインクリメントに変えるという意味になります。

「品質を低下させない」というのはとても大切です。短いタイムボックスで区切られているため焦る気持ちもありますが、品質をおざなりにすると後になってスピードが大きく下がることになります。むしろ、スピードを上げるためには品質を上げるという意識が大切です。

プロダクトバックログのリファインメント（詳細化、優先順位付け、見積もり、最新化などの作業）について、最新版のスクラムではアクティビティという位置付けであり、イベントとは定義されておりません。ただ、必要があれば定期的なミーティングとして設定することもできます。ちなみに、大規模スクラムのフレームワークであるLeSSでは、プロダクトバックログリファインメントが公式なイベントとされています。リファインメントはプロダクトの中長期計画の側面もあり、複数チームで定期的に同期を取ることがより重要であるためです。

バーンダウンチャートを使っているアジャイルチームは多いと思います。ただ、スクラムのフレームワークには含まれないものとなっています。スクラムはフレームワークであるため、意図的に必要最低限のものだけにされています。そのため、バーンダウンチャートなどのプラクティスは使ってもいいし、使わなくてもよいです。

バーンダウンチャートはスプリントプランニングで見積もったストーリーポイントや時間の消化を見ていくものですが、これだけでチームやプロダクトの状態を判断できるものではありません。

ちなみに、ユーザーストーリーやストーリーポイント、ベロシティについてもスクラムには含まれていません。ユーザーストーリーはXPですね。

ただ、スクラムとXP（エクストリームプログラミング）はとても相性が良いため、組み合わせて使われることがとても多いです。スクラムという骨組みの中をXPで埋めるのです。例えば、TDDやペアプログラミング、CI/CDはかなり強力です。逆に、XPを使わないアジャイルチームを見たことはありません。

スプリント中止（スプリントストップ）はかなり強力なインパクトをチームに与えます。これを使うならそれなりの説明と理解が必要ですし、スプリントを立て直すための対策もしっかりとしたものが必要です。そして、通常、再開するときは同じリズム（開始の曜日を変えない）にすることが多いようです。

スプリントプランニング | Sprint Planning

スプリントプランニングはスプリントの起点であり、ここではスプリントで実行する作業の計画を立てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の人をスプリントプランニングに招待してもよい。
スプリントプランニングは次のトピックに対応する：
トピック 1：このスプリントはなぜ価値があるのか？
プロダクトオーナーは、プロダクトの価値と有用性を今回のスプリントでどのように高めることができるかを提案する。次に、スクラムチーム全体が協力して、そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。スプリントゴールは、スプリントプランニングの終了までに確定する必要がある。
トピック 2：このスプリントで何ができるのか？
開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。それによって、チームの理解と自信が高まる。スプリント内でどれくらい完了できるかを選択するのは難しいかもしれない。しかしながら、開発者が過去の自分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めていけば、スプリントの予測に自信が持てるようになる。
トピック 3：選択した作業をどのように成し遂げるのか？
開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメントを作成するために必要な作業を計画する。これは多くの場合、プロダクトバックログアイテムを 1 日以内の小さな作業アイテムに分解することによって行われる。これをどのように行うかは、開発者だけの裁量とする。プロダクトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてくれない。
スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれらを提供するための計画をまとめてスプリントバックログと呼ぶ。
スプリントが 1 か月の場合、スプリントプランニングのタイムボックスは最大で 8 時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。
スクラムガイド（2020）

なぜ、スプリントプランではなくスプリントプランニングであるかというと、一度計画を立てたら終わりではなく、計画をづくりが重要だからです。スクラムではスプリントごとに強制的に計画を立てるように組み立てられています。

ウォーターフォールでは一度立てた計画を遵守して、計画に合わせることが是とされています。そして、変更した方が良いと気づきながらも、変更するためのコストが大きかったり、タイミングを逃したりして、古くなった計画のままで開発が進んでしまうことがよくあります。

スプリントプランニングの主な目的は、スプリントの対象とするプロダクトバックログを選択することと、それをスプリントでやりきるための計画を立てることです。計画を立てるためにプロダクトバックログをタスクレベルにまで分解します。

スプリントの期間は一定ですが、祝祭日があったり、チームメンバーの休日があったり、何らかプロダクト開発外に時間を取られることもあるかもしれません。そのようなことも踏まえて、ある程度、開発者がやり切れると自信を持てる計画を立てたいものです。

一般的に、見積もった時間より多くの作業時間がかかることの方が多いため、スプリントの全体としてのバッファを持てるとなお良いです。

デイリースクラム | Daily Scrum

デイリースクラムの目的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。
デイリースクラムは、スクラムチームの開発者のための15 分のイベントである。複雑さを低減するために、スプリント期間中は毎日、同じ時間・場所で開催する。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。
開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの 1 日の作業の実行可能な計画を作成する限り、必要な構造とやり方を選択できる。これは集中を生み出し、自己管理を促進する。
デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする。開発者が計画を調整できるのは、デイリースクラムのときだけではない。スプリントの残りの作業を適応または再計画することについて、より詳細な議論をするために、開発者は一日を通じて頻繁に話し合う。
スクラムガイド（2020）

以前のスクラムガイドでは、下記の3つの問いに答えるものとなっておりました。

昨日やったこと
今日やること
障害になっていること（スプリントゴールを達成するにあたって）

別に上記が不要になったわけではなく、これが効果的なチームは続けると良いと思います。

ただ、スクラムというフレームワークがソフトウェア開発以外にも適用されていくにあたって、必ず上記の3つの問いがベストとは限らないため、省かれたようです。

「15分のイベント」とありますが「15分以内のイベント」と読み替えていただければと思います。15分を超えてしまう場合はおそらく何かしらの問題を抱えていますので、それを特定して改善するとよいでしょう。例えば下記のような場合にデイリースクラムが長引きがちです。

全員が集まらなくてもよい話題でディスカッションをしている
ふだんのコミュニケーションが不足している
タイムボックスに対する意識が弱い

「プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。」との記載は注意が必要かと思います。

基本的には、プロダクオーナーとスクラムマスターと開発者は求められている責任や視点が異なるため、スプリントバックログのアイテムは開発者が集中した方がよいと考えております。ただ、スクラムがソフトウェア開発以外の業態にも適応していることから、プロダクトオーナーとスクラムマスターを除外するものではない、程度に捉えておいた方が良さそうです。

開発者がやり方を選択することで自己管理が促進されるというのは、とてもアジャイル的、スクラム的です。仕事は与えられるものではなく、自らの意思で引っ張ってくるものです。

スプリントレビュー | Sprint Review

スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う。
スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビューする。この情報に基づいて、参加者は次にやるべきことに協力して取り組む。新たな機会に見合うようにプロダクトバックログを調整することもある。スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする。
スプリントレビューは、スプリントの最後から 2 番目のイベントであり、スプリントが 1 か月の場合、タイムボックスは最大 4 時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。
スクラムガイド（2020）

よくあるスプリントレビューの誤解は、開発者がプロダクトをデモしてプロダクトオーナーが判定する、というものです。これは大きな間違いです。

もし、その場でたくさんの指摘を受けてしまったら、そのスプリントでは完成していないスプリントバックログが溢れ、次のスプリントプランニングにまともに入れない状態となってしまいます。

そのため、スプリントレビューに入る前に、全てのスプリントバックログの完成の定義を満たし、プロダクトオーナーは現物のプロダクトをしっかりと確認しておきます。それによって、スプリントレビューの場はステークホルダーと中長期的な話し合いができるようになります。

スプリントレビューというのは、継続的に成長し続けるプロダクトのスナップショットをチェックしていく場であって、スプリントバックログのアイテムをチェックする場ではないのです。

スプリントレトロスペクティブ | Sprint Retrospective

スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。
スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発生したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。
スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加することもできる。
スプリントレトロスペクティブをもってスプリントは終了する。スプリントが 1 か月の場合、スプリントレトロスペクティブは最大 3 時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。
スクラムガイド（2020）

スプリントレビューではプロダクトを検査しますが、スプリントレトロスペクティブ（レトロ、もしくは、ふりかえり、と呼ばれることが多い）ではプロダクト以外の要素を検査します。

特に、スクラムチームの状態を検査し、課題を特定し、解決策（アクションアイテム）を出し、次のスプリントでそのアクションを実行する、というサイクルを回すことが一般的にです。

レトロ（ふりかえり）のやり方は多くありますが、KPT（ケプト：Keep/Problem/Try）と呼ばれる手法を使うチームが多いようです。

書籍としては下記の2つがとても有名（おすすめ）です。

ちなみに、スプリントレトロスペクティブはチームが改善していくにあたって、もっとも重要なイベントであるため、どんなに忙しくとも省略しないようにしましょう。

また、このイベントの参加者は、プロダクトオーナー、スクラムマスター、開発者のスクラムチームの全員となります。以前はプロダクトオーナーがオプショナル（任意参加）でしたが、最新版では全員が必須となっております。

スクラムの作成物 | Scrum Artifacts

スクラムの作成物は、作業や価値を表している。これらは重要な情報の透明性を最大化できるように設計されている。作成物を検査する人が、適応するときと同じ基準を持っている。
各作成物には、透明性と集中を高める情報を提供する「確約（コミットメント）」が含まれている。これにより進捗を測定できる。
　・プロダクトバックログのためのプロダクトゴール
　・スプリントバックログのためのスプリントゴール
　・インクリメントのための完成の定義
これらの確約は、スクラムチームとステークホルダーの経験主義とスクラムの価値基準を強化するために存在する。
スクラムガイド（2020）

プロダクトバックログ | Product Backlog

プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧である。これは、スクラムチームが行う作業の唯一の情報源である。
1 スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。作業を行う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を支援することもできる。
スクラムガイド（2020）

プロダクトバックログはプロダクトに対する未来の意思が含まれています。プロダクトバックログを見るだけで、そのスクラムチームの力（成熟度）が分かる、という人もいます。

プロダクトに対する要求、作業、改善活動が全て含まれ、かつ、全てが優先順位順に並んでいる必要があります。

アジャイルでは「優先度」と「優先順位」を明確に区別することが多く、後者が好まれます。例えば「優先度：高」ばかりが並んだら、何が優先かわかりません。しかし、順位がついていれば上から順番に実行していくことができます。

唯一の情報源、という状態にすることも透明性を高める上で非常に重要です。

やるべきことが複数箇所に点在していたら、何から始めればよいかわかりませんし、重複していたり同期が取れていなかったら誤った作業をしてしまうこともあるでしょう。

「リファインメント」という言葉は耳慣れないかもしれません。これはプロダクトバックログを最新化、詳細化、具体化していく活動です。優先順位の低いプロダクトバックログのアイテムは粗くて構いませんが、高いものは詳細化しておかないとスプリントに入れることができません。

確約（コミットメント）：プロダクトゴール

プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。
プロダクトとは価値を提供する手段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。
プロダクトゴールは、スクラムチームの長期的な目標である。次の目標に移る前に、スクラムチームはひとつの目標を達成（または放棄）しなければならない。
スクラムガイド（2020）

スプリントバックログ | Sprint Backlog

スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実行可能な計画（どのように）で構成される。
スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで行う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。
スクラムガイド（2020）

スプリントバックログ＝プロダクトバックログアイテム＋実行可能な計画＋スプリントゴール

プロダクトバックログアイテムを選べばいい（＝プロダクトバックログ）、と思っている人は誤解です。

そのスプリント期間で完成の定義を満たすための計画、戦略を立てる必要があります。そのため、多くの場合はプロダクトバックログアイテムをタスクに分解します。

そして、スプリントゴールに向けてのその計画や戦略に問題ないかを毎日のデイリースクラムで検査します。

確約（コミットメント）：スプリントゴール

スプリントゴールはスプリントの唯一の目的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。スプリントゴールはまた、一貫性と集中を生み出し、スクラムチームに一致団結した作業を促すものでもある。
スプリントゴールは、スプリントプランニングで作成され、スプリントバックログに追加される。開発者がスプリントで作業するときには、スプリントゴールを念頭に置く。作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。
スクラムガイド（2020）

インクリメント | Increment

インクリメントは、プロダクトゴールに向けた具体的な踏み石である。インクリメントはこれまでのすべてのインクリメントに追加する。また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。価値を提供するには、インクリメントを利用可能にしなければならない。
スプリントでは、複数のインクリメントを作成可能である。インクリメントをまとめたものをスプリントレビューで提示する。それによって、経験主義がサポートされる。ただし、スプリント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。スプリントレビューのことを価値をリリースするための関門と見なすべきではない。
完成の定義を満たさない限り、作業をインクリメントの一部と見なすことはできない。
スクラムガイド（2020）

スクラムはプロダクトをインクリメンタル（漸進的に）に作っていくということで、スプリント単位に積み重ねていきます。そして、当該スプリントで開発したところだけでなく、これまで積み重ねてきたもの全てを含めて機能するということを検証し、品質が確保できているということを確認します。

これの品質を作り込んでいく活動をスプリント単位にやっておかないと、リスクがどんどん積み上がり、いつか爆発します。

スプリント終了前にデリバリー（リリース）できるというのは少し不思議に感じるかもしれません。スプリントレビューはプロダクトの中長期計画のためにプロダクトのスナップショットを見るのであって、品質の関門ではありません。プロダクトのデモだけで品質が十分に確保されているかどうかはわかりませんね。

スプリントの活動の中で完成の定義を満たしていき、品質の確保がされていればデリバリー（リリース）できるということになります。

ただ、現実的にはデリバリー（リリース）するという行為はリスクをともないますので、プロダクトオーナーやステークホルダーの合意をもってからする方がよいと考えています。

確約（コミットメント）：完成の定義

完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。
プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する。
完成の定義により、作業が完了してインクリメントの一部となったことが全員の共通認識となり、透明性が生み出される。プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。ましてやスプリントレビューで提示することもできない。そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。
インクリメントの完成の定義が組織の標準の一部となっている場合、すべてのスクラムチームは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必要がある。
開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場合、共通の完成の定義を作成して、それに準拠する必要がある。
スクラムガイド（2020）

完成の定義とはリリース可能な品質を確保するためのやるべき作業の一覧です。

例えば、テストコード、リファクタリング、ソースレビュー、E2Eテスト、探索的テストなどがあげられるでしょう。

完成の定義は最初にスクラムチーム全体で合意し、プロダクトバックログアイテムの開発ごとに全て満たせているかを検査しましょう。もし、定義に足りないものあったら追加することや、作業を軽減するために自動化などを検討します。

この完成の定義が本当に品質を確保する条件として必要十分か、おざなりにならずにしっかりとプロセスが回っているかどうかをスプリントレトロスペクティブにて検査します。

最後に | End Note

スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてを備えたものがスクラムであり、その他の技法・方法論・プラクティスの入れ物として機能するものである。
スクラムガイド（2020）

謝辞 | Acknowledgements

人々 | People

スクラムに貢献してくれた多くの方々の中でも、最初に尽力してくれた人物の名前を挙げたい。まず、Jeff Sutherland と一緒に働いた Jeff McKenna と John Scumniotales。それから、Ken Schwaber と一緒に働いた Mike Smith と Chris Martin。みんなで一緒に働いたこともあった。その後の数年間は、さらに多くの方々が貢献してくれた。彼らの助けがなければ、スクラムは今日のように洗練されていなかっただろう。
スクラムガイド（2020）

スクラムガイドの歴史 | Scrum Guide History

Ken Schwaber と Jeff Sutherland が、1995 年の OOPSLA カンファレンスにおいてスクラムを共同発表した。この発表は、Ken と Jeff が過去数年間で学んだことを文書化したものであり、はじめて公開された正式なスクラムの定義である。
スクラムガイドは、Jeff Sutherland と Ken Schwaber が 30 年以上かけて開発・進化・保守しているスクラムを文書化したものである。その他の情報源では、スクラムフレームワークを補完するパターン、プロセス、インサイトなどが提供されている。これらは、生産性・価値・創造性・結果に対する満足度を高める可能性がある。
スクラムの詳細な歴史については、別のところで説明されている。初期の試行錯誤および証明の場である Individual, Inc.、Newspage、Fidelity Investments、IDX（現 GE Medical）の各社に感謝したい。
スクラムガイド（2020）

翻訳について

本ガイドは、上記の開発者による英語バージョンを日本語に翻訳したものである。日本語訳は角征典、荒本実、和田圭介が担当した。
過去の版の翻訳レビューについては、守田憲司さん、高江洲睦さん、永瀬美穂さん、栗秋宏徳さん、川口恭伸さん、角谷信太郎さん、木村卓央さん、原田騎郎さん、吉羽龍太郎さん、むらはしけんいちさん、いろさん、たなべすなおさんに協力いただいた。
スクラムガイド（2020）

スクラムガイド2017年版からスクラムガイド2020年版への変更点

指示的な部分を削減

スクラムガイドは時間が経つにつれて少し指示的なものになっていた。2020 年版では、指示的な表現を削除または緩和して、スクラムを最小限かつ十分なフレームワークに戻すことを目的としている。たとえば、デイリースクラムの質問の削除、PBI（プロダクトバックログアイテム）の属性に関する記述の緩和、スプリントバックログにあるレトロスペクティブのアイテムに関する記述の緩和、スプリントの中止のセクションの削減などを実施した。
スクラムガイド（2020）

ひとつのチームがひとつのプロダクトに集中する

これはチーム内で分断が発生し、PO と開発チームの関係が「プロキシ」や「我々と彼ら」といった問題につながることを排除するためである。存在するのは、PO、SM、開発者の 3 つの異なる責任を持ち、同じ目的を共有するひとつの「スクラムチーム」だけである。
スクラムガイド（2020）

プロダクトゴールの導入

スクラムガイド 2020 年版では「プロダクトゴール」を導入した。スクラムチームに大きな価値のある目的に集中してもらうためである。各スプリントでは、プロダクトを全体的なプロダクトゴールに近づける必要がある。
スクラムガイド（2020）

スプリントゴール、完成の定義、プロダクトゴールの居場所

以前のスクラムガイドでは、明確なアイデンティティーを与えることなく、「スプリントゴール」と「完成の定義」について説明していた。これらは作成物ではなく、作成物に付随するものだった。2020 年版では「プロダクトゴール」を導入し、これらの位置づけを明確にした。3 つの作成物には、それぞれの「確約（コミットメント）」が含まれる。つまり、プロダクトバックログにはプロダクトゴール、スプリントバックログにはスプリントゴール、インクリメントには完成の定義（カッコをなくした）が含まれる。これらの存在により透明性がもたらされ、作成物の進捗に集中できるようになる。
スクラムガイド（2020）

完成の定義は「Doneの定義」や「DoD」と呼ばれることもあります。以前は「完了の定義」と呼ばれていたこともありますが、本質的にはどれも同じです。

また、そのほかにも「ベロシティ」、「ストーリーポイント」、「バーンダウンチャート」、「インセプションデッキ」などがアジャイルやスクラムの中で使われることが多いのですが、スクラムには含まれません。

スクラムはシンプルにシンプルになろうとして、さまざまなものが削ぎ落とされてきたからです。

ただ、スクラムに含まれないからといって使ってはいけないというわけではなく、まずはスクラムが本当に大事としていることを優先した上で、そのチームに必要なプラクティクスを入れていくことがおすすめです。

おそらく、組織やチーム、個人が何らかの目的（ゴール）を達成するためにスクラムを導入しています。そのため、スクラムには「手段」という要素があります。

そのため、少しスクラムの定義から外れた、含まれないからといって「スクラム警察」のように立ち振る舞ってしまうことは控えたいものです。