- スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークである。本ガイドでは、スクラムの定義を説明する。スクラムの定義には、スクラムの役割・イベント・作成物と、それらをまとめるルールが含まれる。スクラムは、Ken SchwaberとJeff Sutherlandが開発したものであり、スクラムガイドはこの2人が執筆・提供する。両者は共にスクラムガイドを支援している。

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

- スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。
+ スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。

- スクラムとは、以下のようなものである。
- 
- * 軽量
- * 理解が容易
- * 習得は困難
+ 簡単に言えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。
+ 
+ * プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。
+ * スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。
+ * スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。
+ * *繰り返す。*
- 
- スクラムは、1990年代初頭から複雑なプロダクトの作業管理に使用されてきたプロセスフレームワークである。プロダクトを構築するプロセス、技法、決定的な方法論などではない。さまざまなプロセスや技法を取り入れることのできるフレームワークである。スクラムは、これまでのプロダクト管理や仕事のテクニックの相対的な有効性を明らかにして、プロダクト・チーム・作業環境の継続的な改善を可能にする。
- 
- スクラムフレームワークは、スクラムチームとその役割・イベント・作成物・ルールで構成されている。それぞれに目的があり、スクラムの成功や利用に欠かせない。
- 
- スクラムのルールは、役割・イベント・作成物をまとめ、それらの関係性や相互作用を統括するものである。スクラムのルールについては、本稿全体で説明する。
- 
- スクラムフレームワークを使用する具体的な方法にはさまざまなものがあり、それらについては本稿では触れない。
+ 
+ スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を生み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する人たちの集合知で構築されている。スクラムのルールは詳細な指示を提供するものではなく、実践者の関係性や相互作用をガイドするものである。
+ 
+ スクラムフレームワークの中で、さまざまなプロセス、技法、手法を使用できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。

- 当初、スクラムはプロダクトの開発と管理のために開発された。1990年代初頭から使用され、今では以下のように世界中で広く利用されている。
- 
- 1. 有望な市場・技術・プロダクトの研究および特定
- 2. プロダクトや追加機能の開発
- 3. プロダクトや追加機能のリリース（1日に何度もリリースされる）
- 4. プロダクトが使用するクラウド（オンライン、セキュア、オンデマンド）やその他運用環境の開発と保守
- 5. プロダクトの保守や刷新
- 
- スクラムは、ソフトウェア、ハードウェア、組込みソフトウェア、機能同士を接続するネットワーク、自動運転車などの開発から、学校、政府、マーケティング、組織運営マネジメントに至るまで、個人や社会が日常的に使用するあらゆるものに使用されている。
- 
- 技術・市場・環境の複雑化やそれらの相互作用は急速に高まっており、スクラムがその対応に有効であることは日々証明されている。
- 
- スクラムは反復的で漸進的な知識移転において特に有効であることが示されている。今では、プロダクト、サービス、所属する組織の管理に広く利用されている。
- 
- スクラムの本質は、少人数制のチームである。個々のチームは非常に柔軟で適応力に優れている。こうした強みは、単一のチームであっても、複数あるいは多数のチームであっても、数千人の成果やプロダクトを開発・リリース・運用・保守するネットワーク型のチームであっても有効である。チームは協力や情報交換をしながら、洗練された開発アーキテクチャやターゲットとするリリース環境を整えていく。
- 
-スクラムガイドで「開発」や「開発する」といった言葉が登場するとき、それは上記のような複雑な作業を意味している。

- スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。
- 
- 経験的プロセス制御の実現は、透明性・検査・適応の3本柱に支えられている。

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

- 経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。
- 例：
- 
- * プロセスの用語を参加者全員で共有している。
- * 作業する人とそのインクリメントを検査する人が「完成」の定義を共有している。
+ 創発的なプロセスや作業は、作業を実行する人とその作業を受け取る人に見える必要がある。スクラムにおける重要な意思決定は、3つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを高める意思決定につながる可能性がある。
+ 透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。

- スクラムのユーザーは、スクラムの作成物やスプリントゴールの進捗を頻繁に検査し、好ましくない変化を検知する。ただし、頻繁にやりすぎて作業の妨げになってはいけない。スキルの高い検査担当者が念入りに行えば、検査は最大の効果をもたらす。
+ スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱心に検査されなければならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、検査を支援するために、5つのイベントでリズムを提供している。
+ 
+ 検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。

- プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断した場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
- 
- スクラムでは、検査と適応のための4つの公式なイベントを規定している。詳しくは、「スクラムイベント」の節で説明する。
- 
- * スプリントプランニング
- * デイリースクラム
- * スプリントレビュー
- * スプリントレトロスペクティブ
+ プロセスのいずれかの側面が許容範囲を逸脱していたり、成果となるプロダクトが受け入れられなかったりしたときは、適用しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最小限に抑えるため、できるだけ早く調整しなければならない。
+ 
+ 関係者に権限が与えられていないときや、自己管理されていないときは、適応が難しくなる。スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。

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

- スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性を最適化するように設計されている。スクラムチームは、前述した用途や複雑な仕事において、非常に高い効果を自ら証明している。
- 
- スクラムチームは、プロダクトを反復的・漸進的に届ける。これは、フィードバックの機会を最大化するためである。「完成」したプロダクトを漸進的に届けることで、動作するプロダクトで役に立つ可能性のあるバージョンを常に利用可能にする。
+ スクラムの基本単位は、スクラムチームという小さなチームである。スクラムチームは、スクラムマスター1人、プロダクトオーナー1人、複数人の開発者で構成される。スクラムチーム内には、サブチームや階層は存在しない。これは、一度にひとつの目的（プロダクトゴール）に集中している専門家が集まった単位である。
+ スクラムチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている。また、自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。
+ スクラムチームは、敏捷性を維持するための十分な小ささと、スプリント内で重要な作業を完了するための十分な大きさがあり、通常は10人以下である。一般的に小さなチームのほうがコミュニケーションがうまく、生産性が高いことがわかっている。スクラムチームが大きくなりすぎる場合は、同じプロダクトに専念した、複数のまとまりのあるスクラムチームに再編成することを検討する必要がある。したがって、同じプロダクトゴール、プロダクトバックログ、およびプロダクトオーナーを共有する必要がある。
+ スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。スクラムチームは、自分たちで作業を管理できるように組織によって構成され、その権限が与えられている。持続可能なペースでスプリントの作業を行うことにより、スクラムチームの集中と一貫性が向上する。
+ スクラムチーム全体が、スプリントごとに価値のある有用なインクリメントを作成する責任を持つ。スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスターという3つの明確な責任を定義する。

- ## 開発チーム
+ ## 開発者

- 開発チームは、各スプリントの終了時にリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されている。「完成」したインクリメントは、スプリントレビューに必要である。インクリメントを作成できるのは、開発チームのメンバーだけである。
- 
- 開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられている。その相乗効果によって、開発チーム全体の効率と効果が最適化される。
- 
- 開発チームには、以下のような特徴がある。
- 
- * 自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。
- * 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
- * ある人にしかできない作業があったとしても、スクラムにおける開発チームのメンバーに肩書きはない。
- * テスティング、アーキテクチャ、運用、ビジネス分析のような専門領域であっても、スクラムは開発チームのサブチームを認めていない。
- * 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。
- 
- ### 開発チームの規模
- 
- 開発チームに最適な人数は、小回りが利く程度に少なく、1つのスプリントで重要な作業が成し遂げられる程度に多い人数である。開発チームのメンバーが3人未満の場合は、相互作用が少なく、生産性の向上につながらない。また、開発チームの規模が小さいと、スキル不足が原因でリリース判断可能なインクリメントを届けられない可能性もある。メンバーが9人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと経験的プロセスが複雑になり、有益ではなくなる。スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスターはこの人数に含まない。
+ 開発者はスクラムチームの一員である。各スプリントにおいて、利用可能なインクリメントのあらゆる側面を作成することを確約する。
+ 
+ 開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。ただし、開発者は常に次の結果に責任を持つ。
+ 
+ * スプリントの計画（スプリントバックログ）を作成する。
+ * 完成の定義を忠実に守ることにより品質を作り込む。
+ * スプリントゴールに向けて毎日計画を適応させる。
+ * 専門家としてお互いに責任を持つ。

- プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。
- 
- プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。プロダクトバックログの管理には、以下のようなものがある。
- 
- * プロダクトバックログアイテムを明確に表現する。
- * ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。
- * 開発チームが行う作業の価値を最適化する。
- * プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を示す。
- * 必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう。
- 
- 上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。
- 
- プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロダクトオーナーと相談しなければいけない。
- 
- プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければいけない。プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。異なる要求の作業を開発チームに強制することは誰にもできない。
+ プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。
+ 
+ プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、
+ 
+ * プロダクトゴールを策定し、明示的に伝える。
+ * プロダクトバックログアイテムを作成し、明確に伝える。
+ * プロダクトバックログアイテムを並び替える。
+ * プロダクトバックログに透明性があり、見える化され、理解されるようにする。
+ 
+ 上記の作業は、プロダクトオーナーが行うこともできるが、他の人に委任することもできる。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。
+ 
+ プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレビューでの検査可能なインクリメントによって見える化される。
+ 
+ プロダクトオーナーは1人の人間であり、委員会ではない。プロダクトオーナーは、多くのステークホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。

- スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。スクラムマスターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援することで、その責任を果たす。
- 
- スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。
+ スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう支援することで、その責任を果たす。
+ スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
+ スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。

- ### スクラムマスターは開発チームを支援する
- スクラムマスターは、さまざまな形で開発チームを支援する。
+ スクラムマスターは、さまざまな形でスクラムチームを支援する。

- * 自己組織化・機能横断的な開発チームをコーチする。
- * 開発チームが価値の高いプロダクトを作れるように支援する。
- * 開発チームの進捗を妨げるものを排除する。
- * 必要に応じてスクラムイベントをファシリテートする。
- * スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。
+ * 自己管理型で機能横断型のチームメンバーをコーチする。
+ * スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できるよう支援する。
+ * スクラムチームの進捗を妨げる障害物を排除するように働きかける。
+ * すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする。

- ### スクラムマスターはプロダクトオーナーを支援する

スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。

- * スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるようにする。
- * 効果的なプロダクトバックログの管理方法を探す。
- * 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
- * 経験主義におけるプロダクトプランニングについて理解する。
- * 価値を最大化するためのプロダクトバックログの調整方法をプロダクトオーナーに把握してもらう。
- * アジャイルを理解・実践している。
- * 必要に応じてスクラムイベントをファシリテートする。
+ * 効果的なプロダクトゴールの定義とプロダクトバックログ管理の方法を探すことを支援する。
+ * 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
+ * 複雑な環境での経験的なプロダクト計画の策定を支援する。
+ * 必要に応じてステークホルダーとのコラボレーションを促進する。

- ### スクラムマスターは組織を支援する

スクラムマスターは、さまざまな形で組織を支援する。

- * 組織へのスクラムの導入を指導・コーチする。
- * 組織へのスクラムの導入方法を計画する。
- * スクラムや経験的プロダクト開発を社員やステークホルダーに理解・実施してもらう。
- * スクラムチームの生産性を高めるような変化を促す。
- * 他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める。
+ * 組織へのスクラムの導入を指導・トレーニング・コーチする。
+ * 組織においてスクラムの実施方法を計画・助言する。
+ * 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。
+ * ステークホルダーとスクラムチームの間の障壁を取り除く。

- スクラムで規定されたイベントは規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化する。すべてのイベントは、時間に上限のあるタイムボックス化されたイベントである。スプリントを開始すると、その期間は固定され、増減することはできない。スプリント以外のイベントについては、目的が達成されたときに終了することもある。これは、プロセスでムダなことをせずに、必要な分だけ時間を使うためである。
- 
- スプリント以外のスクラムイベントは、何かを検査・適応するための公式な機会である（スプリントはその他のイベントの入れ物である）。これらのイベントは、非常に重要な透明性と検査の両方が実現できるように設計されている。これらのイベントがなければ、透明性は低下し、検査・適応の多くの機会を失う。
+ スプリントは他のすべてのイベントの入れ物である。スクラムにおけるそれぞれのイベントは、スクラムの作成物の検査と適応をするための公式の機会である。これらのイベントは必要な透明性を実現するために明確に設計されている。規定通りにイベントを運用しなければ、検査と適応の機会が失われる。スクラムにおけるイベントは、規則性を生み、スクラムで定義されていない会議の必要性を最小限に抑えるために用いられる。
+ すべてのイベントは、複雑さを低減するために、同じ時間と場所で開催されることが望ましい。

- スクラムの中心はスプリントである。これは、「完成」した、利用可能な、リリース判断可能なプロダクトインクリメントを作るための、1か月以下のタイムボックスである。開発中はスプリントの長さは常に一定である。スプリントが終了すると、すぐに新しいスプリントが開始される。
- 
- スプリントは、スプリントプランニング・デイリースクラム・開発作業・スプリントレビュー・スプリントレトロスペクティブで構成される。
+ スプリントはスクラムにおける心臓の鼓動であり、スプリントにおいてアイデアが価値に変わる。
+ 一貫性を保つため、スプリントは1か月以内の決まった長さとする。前のスプリントが終わり次第、新しいスプリントが始まる。
+ スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で行われる。

スプリントでは、

- * スプリントゴールに悪影響を及ぼすような変更を加えない。
- * 品質目標を下げない。
- * 学習が進むにつれてスコープが明確化され、プロダクトオーナーと開発チームの交渉が必要になる可能性がある。
+ * スプリントゴールの達成を危険にさらすような変更はしない。
+ * 品質を低下させない。
+ * プロダクトバックログを必要に応じてリファインメントする。
+ * 学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要になる場合がある。

- スプリントは1か月以内のプロジェクトと考えることができる。プロジェクトと同様に、スプリントは何かを成し遂げるために使うものである。スプリントには、開発対象のゴール、開発のための設計や柔軟な計画、実際の作業、成果となるプロダクトインクリメントが含まれる。
- 
- スプリントの期間は1か月以内に制限されている。スプリントが長すぎると、開発対象の定義が変更されたり、複雑になったり、リスクが増大したりする可能性がある。ゴールに対する進捗を少なくとも1か月ごとに検査・適応することで、予測可能性が高まるのである。また、リスクも1か月分のコストに収まるようになる。

+ スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも1か月ごとに確実になり、予測可能性が高まる。スプリントの期間が長すぎると、スプリントゴールが役に立たなくなり、複雑さが増し、リスクが高まる可能性がある。スプリントの期間を短くすれば、より多くの学習サイクルを生み出し、コストや労力のリスクを短い時間枠に収めることができる。スプリントは短いプロジェクトと考えることもできる。
+ 
+ 進捗の見通しを立てるために、バーンダウン、バーンアップ、累積フローなど、さまざまなプラクティスが存在する。これらの有用性は証明されているが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに発生したことだけが、将来を見据えた意思決定に使用できる。

- ## スプリントの中止
- 
- スプリントはタイムボックスの終了前に中止できる。スプリントを中止する権限があるのは、プロダクトオーナーだけである。このときに、ステークホルダー・開発チーム・スクラムマスターの意見を参考にすることもできる。
- 
- スプリントゴールが古くなった場合は、スプリントを中止することになるだろう。会社の方向性や市場・技術の状況が変化すると、スプリントゴールは古くなってしまう。状況を考慮して意味がなくなったと思えば、スプリントを中止すべきである。ただし、スプリントの期間は短いので、中止したからといって影響があることはほとんどない。
- 
- スプリントを中止した場合は、プロダクトバックログの「完成」したアイテムをレビューする。部分的にリリース判断可能なものについては、通常はプロダクトオーナーが受け入れる。未完成のプロダクトバックログアイテムは、再見積りをしてからプロダクトバックログに戻す。そこにかかった作業の価値は急速に低下するため、頻繁に再見積りが必要になる（訳注：作りかけの機能や設計については、時間が経つと状況が変わってしまうため、その価値が失われてしまうことが多い。そうすると、最初から見積りをやり直す必要が出てくる）。
- 
- スプリントを中止すると、新しいスプリントのスプリントプランニングのために全員が再度集まる必要があり、リソースを消費してしまう。また、スプリントの中止がチームのトラウマになってしまうこともある。とはいえ、スプリントの中止はめったに発生しない。
+ スプリントゴールがもはや役に立たなくなった場合、スプリントは中止されることになるだろう。プロダクトオーナーだけがスプリントを中止する権限を持つ。

- スプリントの作業はスプリントプランニングで計画する。これはスクラムチームの共同作業である。
- 
- スプリントが1か月の場合、スプリントプランニングのタイムボックスは最大で8時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。スクラムマスターは、参加者に目的を理解してもらうようにする。スクラムマスターは、スクラムチームにタイムボックスを守るように伝える。
- 
- * スプリントの成果であるインクリメントで何を届けることができるか？
- * インクリメントを届けるために必要な作業をどのように成し遂げるか？
+ スプリントプランニングはスプリントの起点であり、ここではスプリントで実行する作業の計画を立てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。
+ 
+ プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の人をスプリントプランニングに招待してもよい。

- スプリントプランニングでは、以下の質問に答える。
+ スプリントプランニングは次のトピックに対応する：

+ ### トピック1：このスプリントはなぜ価値があるのか？
+ 
+ プロダクトオーナーは、プロダクトの価値と有用性を今回のスプリントでどのように高めることができるかを提案する。次に、スクラムチーム全体が協力して、そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。スプリントゴールは、スプリントプランニングの終了までに確定する必要がある。

- ### トピック1：スプリントで何ができるか？
+ ### トピック2：このスプリントで何ができるのか？ 

- 開発チームは、スプリントで開発できそうな機能を予想する。プロダクトオーナーは、スプリントで達成すべき目的と、完成すればスプリントゴールを達成できそうなプロダクトバックログアイテムについて検討する。スクラムチームはみんなで協力して、スプリントの作業を理解する。
- 
- スプリントプランニングのインプットは、プロダクトバックログ、最新のプロダクトインクリメント、開発チームが予想するキャパシティと過去の実績である。プロダクトバックログから選択するアイテム数については、開発チームが責任を持つ。スプリントで何を達成するかを評価できるのは、開発チームだけである。
- 
- スプリントプランニングでは、スクラムチームがスプリントゴールを設定する。スプリントゴールとは、プロダクトバックログを実装することで実現するスプリントの目的であり、開発チームがインクリメントを開発する指針となるものである。
+ 開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。それによって、チームの理解と自信が高まる。
+ 
+ スプリント内でどれくらい完了できるかを選択するのは難しいかもしれない。しかしながら、開発者が過去の自分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めていけば、スプリントの予測に自信が持てるようになる。

- ### トピック2：選択した作業をどのように成し遂げるか？
+ ### トピック3：選択した作業をどのように成し遂げるのか？

- プロダクトバックログアイテムを選択し、スプリントゴールを設定したら、開発チームはスプリントでそれらの機能を「完成」したプロダクトインクリメントにする方法を決める。選択したプロダクトバックログアイテムとそれらを届ける計画を合わせて、スプリントバックログと呼ぶ。
- 
- 開発チームは、プロダクトバックログを動作するプロダクトインクリメントに変えるために必要なシステムと作業の設計から着手する。作業の規模や工数はバラバラであっても構わないが、開発チームが次のスプリントで実現できそうなものを計画する。開発チームがスプリントの最初の数日間で行う作業については、スプリントプランニングで作業に分解する。作業の単位は1日以下にするこ
- 
- とが多い。開発チームは自己組織化して、スプリントバックログの作業を引き受ける。これはスプリントプランニングだけでなく、必要であればスプリントでも行う。
- 
- プロダクトオーナーは、選択したプロダクトバックログアイテムの明確化やトレードオフを支援する。開発チームの作業が多すぎたり少なすぎたりした場合は、選択されたプロダクトバックログアイテムについて、開発チームとプロダクトオーナーで話し合う。あるいは、技術やドメインに詳しい人を招待してアドバイスを求めることもできる。
- 
- スプリントプランニングが終了するまでに、開発チームは自己組織化したチームとして、どのようにスプリントゴールを達成し、どのように期待されるインクリメントを作成するかをプロダクトオーナーとスクラムマスターに説明できなければいけない。

+ 開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメントを作成するために必要な作業を計画する。これは多くの場合、プロダクトバックログアイテムを1日以内の小さな作業アイテムに分解することによって行われる。これをどのように行うかは、開発者だけの裁量とする。プロダクトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてくれない。
- ### スプリントゴール
- 
- スプリントゴールはスプリントの目的の集合であり、プロダクトバックログの実装によって実現するものである。これは開発チームがインクリメントを構築する理由を知る指針となる。スプリントゴールはスプリントプランニングで作成する。スプリントゴールを設定することで、開発チームがスプリント終了までに実装する機能を柔軟にできる。選択したプロダクトバックログアイテムは、一貫性のある機能として届けられる。それがスプリントゴールになることもある。スプリントゴールがあれば、開発チームは一致団結して作業ができる。
- 
- 開発チームが作業するときには、スプリントゴールを念頭に置く。スプリントゴールを達成するために、機能や技術を実装する。開発チームの予想と異なることが判明した場合は、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。
+ スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれらを提供するための計画をまとめてスプリントバックログと呼ぶ。
+ 
+ スプリントが1か月の場合、スプリントプランニングのタイムボックスは最大で8時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。

- デイリースクラムとは、開発チームのための15分間のタイムボックスのイベントである。スプリントでは、毎日デイリースクラムを開催する。開発チームは、次の24時間の作業を計画する。前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をすることで、チームのコラボレーションやパフォーマンスを最適化するのである。デイリースクラムは毎日、同じ時間・場所で開催し、複雑にならないようにする。
- 
- 開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの進捗を検査する。デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。
- 
- デイリースクラムの構成は、開発チームが設定する。スプリントゴールを目指している限り、他のやり方で行なっても構わない。質問を使うチームもあれば、議論ベースで進めるチームもある。たとえば、以下のような例を使用するといいだろう。
- 
- * 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
- * 開発チームがスプリントゴールを達成するために、私が今日やることは何か？
- * 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？
- 
- 開発チームやチームメンバーは、デイリースクラムの終了直後に集まり、スプリントの残作業について、詳細な議論・適応・再計画を行うこともある。
- 
- スクラムマスターは、開発チームにデイリースクラムを開催してもらうようにする。ただし、デイリースクラムを開催する責任は開発チームにある。スクラムマスターは、デイリースクラムを15分間のタイムボックスで終わらせるように開発チームに伝える。
- 
- デイリースクラムは開発チームのためのミーティングである。それ以外の人たちが参加する場合、開発チームの邪魔にならないようにスクラムマスターが配慮する。
- 
- デイリースクラムは、コミュニケーションを改善し、その他のミーティングを取り除き、開発の障害物を特定・排除し、迅速な意思決定を強調・助長して、開発チームのプロジェクト知識のレベルを向上させるものである。これは、検査と適応の重要なイベントである。
+ デイリースクラムの目的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。
+ 
+ デイリースクラムは、スクラムチームの開発者のための15分のイベントである。複雑さを低減するために、スプリント期間中は毎日、同じ時間・場所で開催する。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。
+ 
+ 開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの1日の作業の実行可能な計画を作成する限り、必要な構造とやり方を選択できる。これは集中を生み出し、自己管理を促進する。
+ 
+ デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする。
+ 
+ 開発者が計画を調整できるのは、デイリースクラムのときだけではない。スプリントの残りの作業を適応または再計画することについて、より詳細な議論をするために、開発者は一日を通じて頻繁に話し合う

- スプリントレビューとは、スプリントの終了時にインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。スプリントレビューでは、スクラムチームとステークホルダーがスプリントの成果をレビューする。スプリントの成果とプロダクトバックログの変更を参考にして、価値を最適化するために次に何ができるかを参加者全員で話し合う。これはステータスミーティングではなく、略式のミーティングである。インクリメントを提示することで、フィードバックや協力を引き出すことを目的とする。
- 
- スプリントが1か月の場合、スプリントレビューは最大4時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。スクラムマスターはスプリントレビューが確実に開催されるようにして、参加者には目的を理解してもらうようにする。スクラムマスターは関係者全員にタイムボックスを守るように伝える。
- 
- スプリントレビューには、以下の要素が含まれる。
- 
- * 参加者は、スクラムチームと、プロダクトオーナーが招待した重要なステークホルダーである。
- * プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないものについて説明する。
- * 開発チームは、スプリントでうまくいったこと、直面した問題点、それをどのように解決したかを議論する。
- * 開発チームは、「完成」したものをデモして、インクリメントに対する質問に答える。「完成」の定義にプロダクト機能のリリースが含まれていれば、それらを表示してレビューしてもらう。
- * プロダクトオーナーは、現在のプロダクトバックログの状況を説明する。（必要であれば）現在の進捗から、可能性のある目標とデリバリーの日程を予測する。
- * グループ全体で次に何をするべきかを議論し、次のスプリントプランニングに価値のあるインプットを提供できるようにする。
- * 市場やプロダクトの利用状況によって、次に行うべき最も価値の高いことが変更される可能性をレビューする。
- * 次にリリースするプロダクトの機能や性能のスケジュール・予算・可能性・市場をレビューする。
- 
- スプリントレビューの成果は、次のスプリントで使用するプロダクトバックログアイテムが含まれた改訂版のプロダクトバックログである。新たな機会に見合うように、プロダクトバックログを全体的に調整することもある。
+ スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う。
+ 
+ スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビューする。この情報に基づいて、参加者は次にやるべきことに協力して取り組む。新たな機会に見合うようにプロダクトバックログを調整することもある。スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする。
+ 
+ スプリントレビューは、スプリントの最後から2番目のイベントであり、スプリントが1か月の場合、タイムボックスは最大4時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。

- スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。
- 
- スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリントプランニングが始まる前に行う。スプリントが1か月の場合、スプリントレトロスペクティブは最大3時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。スクラムマスターは、このイベントが確実に開催されるようにする。また、参加者に目的を理解してもらうようにする。
- 
- スクラムマスターは、このミーティングがポジティブで生産的になるようにする。スクラムマスターは、全員にタイムボックスを守るように伝える。スクラムマスターは、スクラムのプロセスを説明するために、チームメンバーとして参加する。
- 
- スプリントレトロスペクティブには、以下の目的がある。
- 
- * 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。
- * うまくいった項目や今後の改善が必要な項目を特定・整理する。
- * スクラムチームの作業の改善実施計画を作成する。
- 
- スクラムマスターは、次のスプリントが効果的で楽しいものになるように、スクラムチームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう。スプリントレトロスペクティブにおいてスクラムチームは、作業プロセスの改善や「完成」の定義を調整することにより、プロダクトの品質を向上させる方法を計画する。ただし、プロダクトや組織の基準と衝突しないように適切に行う。
- 
- スプリントレトロスペクティブが終わるまでに、スクラムチームは次のスプリントで実施する改善策を特定しなければいけない。これらの改善策の実施は、スクラムチーム自体の検査に対する適応になる。改善はいつでも実施可能だが、スプリントレトロスペクティブは検査と適応に集中するための公式な機会である。
+ スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。
+ 
+ スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発生したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。
+ 
+ スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加することもできる。
+ 
+ スプリントレトロスペクティブをもってスプリントは終了する。スプリントが1か月の場合、スプリントレトロスペクティブは最大3時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。

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

- プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。プロダクトに対する変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログの内容・可用性・並び順に責任を持つ。
- 
- プロダクトバックログは決して完成しない。構築の初期段階には、明確でよく理解できている要求が並べられている。その後、プロダクトや使用環境に合わせて進化する。プロダクトバックログは動的であり、適切で競争力のある有用なプロダクトに必要なものを求めて絶えず変化する。プロダクトが存在する限り、プロダクトバックログも存在し続けるのである。
- 
- プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正をすべて一覧にしている。プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。プロダクトバックログアイテムには、「完成」時にそれを確認するためのテスト記述も含まれていることが多い。
- 
- プロダクトが使用されて価値が増加し、市場からフィードバックを得られると、プロダクトバックログは巨大で包括的な一覧になる。要求の変更は止まらない。プロダクトバックログは生きた作成物である。ビジネス要求、市場の状態、技術の変化などが、プロダクトバックログの変化につながる。
- 
- 複数のスクラムチームが同じプロダクトの作業をすることがよくある。そうした場合、プロダクトの作業は1つのプロダクトバックログに記述する。また、アイテムを分類するための属性をプロダクトバックログに追加することもある。
- 
- プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。プロダクトバックログのリファインメントによって、アイテムのレビューと改訂が行われる。いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメントは、開発チームの作業の10%以下にすることが多い。ただし、プロダクトバックログアイテムはプロダクトオーナーの判断によって、いつでも更新できる。
- 
- 並び順が上のプロダクトバックログアイテムほど明確で詳細である。明確で詳細であれば、見積りも正確になる。並び順が下のアイテムほど不正確で詳細ではない。今後のスプリントで開発チームが従事するプロダクトバックログアイテムは、スプリントのタイムボックスで「完成」できるようにうまく細分化する。開発チームが1つのスプリントで「完成」できそうなプロダクトバックログアイテムは、スプリントプランニングで選択できる「準備完了（Ready）」の状態になったと見なすことができる。プロダクトバックログアイテムは、上記のリファインメントによって透明性を獲得することが多い。
- 
- 開発チームは見積りに対して責任を持つ。プロダクトオーナーがトレードオフの理解や選択などについて開発チームに影響を及ぼすこともあるが、最終的な見積りは実際に作業をする人が行う。
+ プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧である。これは、スクラムチームが行う作業の唯一の情報源である。
+ 
+ 1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。
+ 
+ 作業を行う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を支援することもできる。

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

- ### ゴールへの進捗を追跡する
- 
- いずれかの時点で、ゴールに対する残作業を合計する。プロダクトオーナーは、少なくともスプリントレビューにおいて、この残作業の合計を追跡する。プロダクトオーナーは、前回のスプリントレビュー時点の残作業の合計と比較して、希望する期日までにゴールに到達できるかどうかを評価する。この情報はステークホルダー全員に明らかにする。
- 
- 進捗の見通しを立てるために、バーンダウン、バーンアップ、累積フローなどのさまざまなプラクティスが使用されている。これらは有用ではあるが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに発生したことだけが、これから先の意思決定に使用できる。

- スプリントバックログは、スプリントで選択したプロダクトバックログアイテムと、それらのアイテムをプロダクトインクリメントにして届け、スプリントゴールを達成するための計画を合わせたものである。スプリントバックログは、次のインクリメントに含まれる機能と、その機能を「完成」したインクリメントにして届けるために必要な作業について、開発チームが予想したものである。
- 
- スプリントバックログによって、開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている。継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも1つは含めておく。
- 
- スプリントバックログは十分に詳細であり、今後も変更される可能性のある計画である。それはデイリースクラムで理解できる程度のものである。開発チームは、スプリントでスプリントバックログを修正する。スプリントバックログはスプリントで創発される。こうした創発が発生するのは、開発チームが計画を実行するなかで、スプリントゴールの達成に必要な作業を学習するからである。
- 
- 新しい作業が必要になれば、開発チームがスプリントバックログに作業を追加する。作業が完了すれば、残作業の見積りを更新する。計画の要素が不要になれば削除する。スプリントでスプリントバックログを変更できるのは開発チームだけである。スプリントバックログには、開発チームがスプリントで行う作業がリアルタイムに反映される。スプリントバックログは開発チームのものである。
+ スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実行可能な計画（どのように）で構成される。
+ 
+ スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで行う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。

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

- ### スプリントの進捗を追跡する
- 
- スプリントのいずれかの時点で、スプリントバックログの残作業を合計する。開発チームは、少なくともデイリースクラムにおいて、この残作業の合計を追跡し、スプリントゴールの達成に見通しを立てる。開発チームはスプリントで残作業を追跡し、自分たちの進捗を管理する。

- インクリメントとは、これまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックログアイテムを合わせたものである。スプリントの終了時には、新しいインクリメントが「完成」していなければいけない。つまり、インクリメントが動作する状態であり、スクラムチームの「完成」の定義に合っていることを意味する。インクリメントは、完成していて、検査可能なものであり、スプリントの終了時の経験主義を支援するものである。インクリメントは、ビジョンやゴールに向かうステップである。プロダクトオーナーがリリースを決定する／しないにかかわらず、インクリメントは常に動作する状態にしておかなければいけない。
+ インクリメントは、プロダクトゴールに向けた具体的な踏み石である。インクリメントはこれまでのすべてのインクリメントに追加する。また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。価値を提供するには、インクリメントを利用可能にしなければならない。
+ 
+ スプリントでは、複数のインクリメントを作成可能である。インクリメントをまとめたものをスプリントレビューで提示する。それによって、経験主義がサポートされる。ただし、スプリント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。スプリントレビューのことを価値をリリースするための関門と見なすべきではない。
+ 
+ 完成の定義を満たさない限り、作業をインクリメントの一部と見なすことはできない。

- ### 作成物の透明性
- 
- スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。作成物の透明性が不完全であれば、こうした決定には不備があり、価値は低減し、リスクが高まる可能性がある。
- 
- スクラムマスターは、プロダクトオーナー、開発チーム、その他の関係者と一緒になって、作成物が完全に透明化されているかを理解する。不完全な透明性に対処するには、いくつかのプラクティスが存在する。スクラムマスターは、そのなかから最適なプラクティスを選択してもらえるように支援する。スクラムマスターは、作成物の検査、パターンの察知、言説の傾聴、期待値と実際値の違いを把握することで、不完全な透明性を検知できる。
- 
- スクラムマスターの仕事は、スクラムチームや組織と一緒になって、作成物の透明性を向上させることである。この仕事には、学習・説得・変化を伴うことが多い。透明性は一夜にしてならず。透明性とは長い道のりなのである。

- ### 「完成（Done）」の定義
- 
- プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の意味を理解しておかなければいけない。スクラムチームによってその意味は大きく異なるかもしれないが、作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。これは、スクラムチームの『「完成」の定義』と呼ばれ、プロダクトインクリメントの作業が完了したかどうかの評価に使われる。
- 
- この定義は、開発チームがスプリントプランニングでプロダクトバックログアイテムをいくつ選択するかの指針にもなる。各スプリントの目的は、そのときの「完成」の定義に合ったリリース判断可能な機能のインクリメントを届けることである。
- 
- 開発チームは、スプリントごとにプロダクトインクリメントを届ける。インクリメントは実際に利用可能なものであり、プロダクトオーナーがすぐにリリースすることもできる。インクリメントの「完成」の定義に関して、開発組織の慣例・標準・ガイドラインが存在する場合は、スクラムチームは最低でもそれを守らなければいけない。
- 
- インクリメントの「完成」の定義が開発組織に存在しない場合は、スクラムチームの開発チームはプロダクトに適した「完成」を定義しなければいけない。複数のスクラムチームがシステムやプロダクトのリリース作業をする場合は、すべてのスクラムチームの開発チームが共通の「完成」の定義を使用しなければいけない。
- 
- インクリメントは、それまでのインクリメントに追加されたものであり、すべてが正常に動くように十分にテストされたものである。
- 
- スクラムチームが成熟していくと、「完成」の定義にさらに厳しい品質条件を追加することもある。新しい定義を作り、それを使用していくと、以前に「完成」したインクリメントにも手を加えなければいけないことが明らかになる可能性がある。あらゆるプロダクトやシステムは「完成」の定義を備えるべきである。それがあらゆる作業の完了基準となる。
+ 完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。
+ 
+ プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する。
+ 
+ 完成の定義により、作業が完了してインクリメントの一部となったことが全員の共通認識となり、透明性が生み出される。プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。ましてやスプリントレビューで提示することもできない。そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。
+ 
+ インクリメントの完成の定義が組織の標準の一部となっている場合、すべてのスクラムチームは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必要がある。
+ 
+ 開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場合、共通の完成の定義を作成して、それに準拠する必要がある。

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