スクラムガイド2017
スクラム公式ガイド:ゲームのルール（2017年10月）
最終更新
スクラム公式ガイド:ゲームのルール（2017年10月）
最終更新
2017年10月
Developed and sustained by Scrum creators: Ken Schwaber and Jeff Sutherland
スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークである。本ガイドでは、スクラムの定義を説明する。スクラムの定義には、スクラムの役割・イベント・作成物と、それらをまとめるルールが含まれる。スクラムは、Ken SchwaberとJeff Sutherlandが開発したものであり、スクラムガイドはこの2人が執筆・提供する。両者は共にスクラムガイドを支援している。
スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。
スクラムとは、以下のようなものである。
軽量
理解が容易
習得は困難
スクラムは、1990年代初頭から複雑なプロダクトの作業管理に使用されてきたプロセスフレームワークである。プロダクトを構築するプロセス、技法、決定的な方法論などではない。さまざまなプロセスや技法を取り入れることのできるフレームワークである。スクラムは、これまでのプロダクト管理や仕事のテクニックの相対的な有効性を明らかにして、プロダクト・チーム・作業環境の継続的な改善を可能にする。
スクラムフレームワークは、スクラムチームとその役割・イベント・作成物・ルールで構成されている。それぞれに目的があり、スクラムの成功や利用に欠かせない。
スクラムのルールは、役割・イベント・作成物をまとめ、それらの関係性や相互作用を統括するものである。スクラムのルールについては、本稿全体で説明する。
スクラムフレームワークを使用する具体的な方法にはさまざまなものがあり、それらについては本稿では触れない。
当初、スクラムはプロダクトの開発と管理のために開発された。1990年代初頭から使用され、今では以下のように世界中で広く利用されている。
有望な市場・技術・プロダクトの研究および特定
プロダクトや追加機能の開発
プロダクトや追加機能のリリース（1日に何度もリリースされる）
プロダクトが使用するクラウド（オンライン、セキュア、オンデマンド）やその他運用環境の開発と保守
プロダクトの保守や刷新
スクラムは、ソフトウェア、ハードウェア、組込みソフトウェア、機能同士を接続するネットワーク、自動運転車などの開発から、学校、政府、マーケティング、組織運営マネジメントに至るまで、個人や社会が日常的に使用するあらゆるものに使用されている。
技術・市場・環境の複雑化やそれらの相互作用は急速に高まっており、スクラムがその対応に有効であることは日々証明されている。
スクラムは反復的で漸進的な知識移転において特に有効であることが示されている。今では、プロダクト、サービス、所属する組織の管理に広く利用されている。
スクラムの本質は、少人数制のチームである。個々のチームは非常に柔軟で適応力に優れている。こうした強みは、単一のチームであっても、複数あるいは多数のチームであっても、数千人の成果やプロダクトを開発・リリース・運用・保守するネットワーク型のチームであっても有効である。チームは協力や情報交換をしながら、洗練された開発アーキテクチャやターゲットとするリリース環境を整えていく。
スクラムガイドで「開発」や「開発する」といった言葉が登場するとき、それは上記のような複雑な作業を意味している。
スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。 経験的プロセス制御の実現は、透明性・検査・適応の3本柱に支えられている。
経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。
例：
プロセスの用語を参加者全員で共有している。
作業する人とそのインクリメントを検査する人が「完成」の定義を共有している。
スクラムのユーザーは、スクラムの作成物やスプリントゴールの進捗を頻繁に検査し、好ましくない変化を検知する。ただし、頻繁にやりすぎて作業の妨げになってはいけない。スキルの高い検査担当者が念入りに行えば、検査は最大の効果をもたらす。
プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断した場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
スクラムでは、検査と適応のための4つの公式なイベントを規定している。詳しくは、「スクラムイベント」の節で説明する。
スプリントプランニング
デイリースクラム
スプリントレビュー
スプリントレトロスペクティブ
スクラムチームが、確約（commitment）・勇気（courage）・集中（focus）・公開（openness）・尊敬（respect）の価値基準を取り入れ、それらを実践するとき、スクラムの柱（透明性・検査・適応）は現実のものとなり、あらゆる人に対する信頼が築かれる。スクラムチームのメンバーは、スクラムの役割・イベント・作成物に触れて仕事を進めるなかで、これらの価値基準を学習・探索する。
スクラムを活用するには、これらの5つの価値基準を上手に実践しなければいけない。個人は、スクラムチームのゴールの達成を確約しなければいけない。スクラムチームのメンバーは、正しいことをする勇気を持ち、困難な問題に取り組まなければいけない。全員が、スプリントの作業とスクラムチームのゴールに集中しなければいけない。スクラムチームとステークホルダーは、すべての仕事とそれらを遂行する上での課題を公開することに合意しなければいけない。スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけない。
スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性を最適化するように設計されている。
スクラムチームは、前述した用途や複雑な仕事において、非常に高い効果を自ら証明している。 スクラムチームは、プロダクトを反復的・漸進的に届ける。これは、フィードバックの機会を最大化するためである。「完成」したプロダクトを漸進的に届けることで、動作するプロダクトで役に立つ可能性のあるバージョンを常に利用可能にする。
プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。
プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。プロダクトバックログの管理には、以下のようなものがある。
プロダクトバックログアイテムを明確に表現する。
ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。
開発チームが行う作業の価値を最適化する。
プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を示す。
必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう。
上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。
プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロダクトオーナーと相談しなければいけない。
プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければいけない。プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。異なる要求の作業を開発チームに強制することは誰にもできない。
開発チームは、各スプリントの終了時にリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されている。「完成」したインクリメントは、スプリントレビューに必要である。インクリメントを作成できるのは、開発チームのメンバーだけである。
開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられている。その相乗効果によって、開発チーム全体の効率と効果が最適化される。
開発チームには、以下のような特徴がある。
自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。
機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
ある人にしかできない作業があったとしても、スクラムにおける開発チームのメンバーに肩書きはない。
テスティング、アーキテクチャ、運用、ビジネス分析のような専門領域であっても、スクラムは開発チームのサブチームを認めていない。
開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。
開発チームに最適な人数は、小回りが利く程度に少なく、1つのスプリントで重要な作業が成し遂げられる程度に多い人数である。開発チームのメンバーが3人未満の場合は、相互作用が少なく、生産性の向上につながらない。また、開発チームの規模が小さいと、スキル不足が原因でリリース判断可能なインクリメントを届けられない可能性もある。メンバーが9人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと経験的プロセスが複雑になり、有益ではなくなる。スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスターはこの人数に含まない。
スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。スクラムマスターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援することで、その責任を果たす。
スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。
スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。
スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるようにする。
効果的なプロダクトバックログの管理方法を探す。
明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
経験主義におけるプロダクトプランニングについて理解する。
価値を最大化するためのプロダクトバックログの調整方法をプロダクトオーナーに把握してもらう。
アジャイルを理解・実践している。
必要に応じてスクラムイベントをファシリテートする。
スクラムマスターは、さまざまな形で開発チームを支援する。
自己組織化・機能横断的な開発チームをコーチする。
開発チームが価値の高いプロダクトを作れるように支援する。
開発チームの進捗を妨げるものを排除する。
必要に応じてスクラムイベントをファシリテートする。
スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。
スクラムマスターは、さまざまな形で組織を支援する。
組織へのスクラムの導入を指導・コーチする。
組織へのスクラムの導入方法を計画する。
スクラムや経験的プロダクト開発を社員やステークホルダーに理解・実施してもらう。
スクラムチームの生産性を高めるような変化を促す。
他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める。
スクラムで規定されたイベントは規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化する。すべてのイベントは、時間に上限のあるタイムボックス化されたイベントである。スプリントを開始すると、その期間は固定され、増減することはできない。スプリント以外のイベントについては、目的が達成されたときに終了することもある。これは、プロセスでムダなことをせずに、必要な分だけ時間を使うためである。
スプリント以外のスクラムイベントは、何かを検査・適応するための公式な機会である（スプリントはその他のイベントの入れ物である）。これらのイベントは、非常に重要な透明性と検査の両方が実現できるように設計されている。これらのイベントがなければ、透明性は低下し、検査・適応の多くの機会を失う。
スクラムの中心はスプリントである。これは、「完成」した、利用可能な、リリース判断可能なプロダクトインクリメントを作るための、1か月以下のタイムボックスである。開発中はスプリントの長さは常に一定である。スプリントが終了すると、すぐに新しいスプリントが開始される。
スプリントは、スプリントプランニング・デイリースクラム・開発作業・スプリントレビュー・スプリントレトロスペクティブで構成される。
スプリントでは、
• スプリントゴールに悪影響を及ぼすような変更を加えない。
• 品質目標を下げない。
• 学習が進むにつれてスコープが明確化され、プロダクトオーナーと開発チームの交渉が必要になる可能性がある。
スプリントは1か月以内のプロジェクトと考えることができる。プロジェクトと同様に、スプリントは何かを成し遂げるために使うものである。スプリントには、開発対象のゴール、開発のための設計や柔軟な計画、実際の作業、成果となるプロダクトインクリメントが含まれる。
スプリントの期間は1か月以内に制限されている。スプリントが長すぎると、開発対象の定義が変更されたり、複雑になったり、リスクが増大したりする可能性がある。ゴールに対する進捗を少なくとも1か月ごとに検査・適応することで、予測可能性が高まるのである。また、リスクも1か月分のコストに収まるようになる。
スプリントはタイムボックスの終了前に中止できる。スプリントを中止する権限があるのは、プロダクトオーナーだけである。このときに、ステークホルダー・開発チーム・スクラムマスターの意見を参考にすることもできる。
スプリントゴールが古くなった場合は、スプリントを中止することになるだろう。会社の方向性や市場・技術の状況が変化すると、スプリントゴールは古くなってしまう。状況を考慮して意味がなくなったと思えば、スプリントを中止すべきである。ただし、スプリントの期間は短いので、中止したからといって影響があることはほとんどない。
スプリントを中止した場合は、プロダクトバックログの「完成」したアイテムをレビューする。部分的にリリース判断可能なものについては、通常はプロダクトオーナーが受け入れる。未完成のプロダクトバックログアイテムは、再見積りをしてからプロダクトバックログに戻す。そこにかかった作業の価値は急速に低下するため、頻繁に再見積りが必要になる（訳注：作りかけの機能や設計については、時間が経つと状況が変わってしまうため、その価値が失われてしまうことが多い。そうすると、最初から見積りをやり直す必要が出てくる）。
スプリントを中止すると、新しいスプリントのスプリントプランニングのために全員が再度集まる必要があり、リソースを消費してしまう。また、スプリントの中止がチームのトラウマになってしまうこともある。とはいえ、スプリントの中止はめったに発生しない。
スプリントの作業はスプリントプランニングで計画する。これはスクラムチームの共同作業である。
スプリントが1か月の場合、スプリントプランニングのタイムボックスは最大で8時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。スクラムマスターは、参加者に目的を理解してもらうようにする。スクラムマスターは、スクラムチームにタイムボックスを守るように伝える。
スプリントプランニングでは、以下の質問に答える。
• スプリントの成果であるインクリメントで何を届けることができるか？
• インクリメントを届けるために必要な作業をどのように成し遂げるか？
開発チームは、スプリントで開発できそうな機能を予想する。プロダクトオーナーは、スプリントで達成すべき目的と、完成すればスプリントゴールを達成できそうなプロダクトバックログアイテムについて検討する。スクラムチームはみんなで協力して、スプリントの作業を理解する。
スプリントプランニングのインプットは、プロダクトバックログ、最新のプロダクトインクリメント、開発チームが予想するキャパシティと過去の実績である。プロダクトバックログから選択するアイテム数については、開発チームが責任を持つ。スプリントで何を達成するかを評価できるのは、開発チームだけである。
スプリントプランニングでは、スクラムチームがスプリントゴールを設定する。スプリントゴールとは、プロダクトバックログを実装することで実現するスプリントの目的であり、開発チームがインクリメントを開発する指針となるものである。
プロダクトバックログアイテムを選択し、スプリントゴールを設定したら、開発チームはスプリントでそれらの機能を「完成」したプロダクトインクリメントにする方法を決める。選択したプロダクトバックログアイテムとそれらを届ける計画を合わせて、スプリントバックログと呼ぶ。
開発チームは、プロダクトバックログを動作するプロダクトインクリメントに変えるために必要なシステムと作業の設計から着手する。作業の規模や工数はバラバラであっても構わないが、開発チームが次のスプリントで実現できそうなものを計画する。開発チームがスプリントの最初の数日間で行う作業については、スプリントプランニングで作業に分解する。作業の単位は1日以下にすることが多い。開発チームは自己組織化して、スプリントバックログの作業を引き受ける。これはスプリントプランニングだけでなく、必要であればスプリントでも行う。
プロダクトオーナーは、選択したプロダクトバックログアイテムの明確化やトレードオフを支援する。開発チームの作業が多すぎたり少なすぎたりした場合は、選択されたプロダクトバックログアイテムについて、開発チームとプロダクトオーナーで話し合う。あるいは、技術やドメインに詳しい人を招待してアドバイスを求めることもできる。
スプリントプランニングが終了するまでに、開発チームは自己組織化したチームとして、どのようにスプリントゴールを達成し、どのように期待されるインクリメントを作成するかをプロダクトオーナーとスクラムマスターに説明できなければいけない。
スプリントゴールはスプリントの目的の集合であり、プロダクトバックログの実装によって実現するものである。これは開発チームがインクリメントを構築する理由を知る指針となる。スプリントゴールはスプリントプランニングで作成する。スプリントゴールを設定することで、開発チームがスプリント終了までに実装する機能を柔軟にできる。選択したプロダクトバックログアイテムは、一貫性のある機能として届けられる。それがスプリントゴールになることもある。スプリントゴールがあれば、開発チームは一致団結して作業ができる。
開発チームが作業するときには、スプリントゴールを念頭に置く。スプリントゴールを達成するために、機能や技術を実装する。開発チームの予想と異なることが判明した場合は、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。
デイリースクラムとは、開発チームのための15分間のタイムボックスのイベントである。スプリントでは、毎日デイリースクラムを開催する。開発チームは、次の24時間の作業を計画する。前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をすることで、チームのコラボレーションやパフォーマンスを最適化するのである。デイリースクラムは毎日、同じ時間・場所で開催し、複雑にならないようにする。
開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの進捗を検査する。デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。
デイリースクラムの構成は、開発チームが設定する。スプリントゴールを目指している限り、他のやり方で行なっても構わない。質問を使うチームもあれば、議論ベースで進めるチームもある。たとえば、以下のような例を使用するといいだろう。
開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
開発チームがスプリントゴールを達成するために、私が今日やることは何か？
私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？
開発チームやチームメンバーは、デイリースクラムの終了直後に集まり、スプリントの残作業について、詳細な議論・適応・再計画を行うこともある。
スクラムマスターは、開発チームにデイリースクラムを開催してもらうようにする。ただし、デイリースクラムを開催する責任は開発チームにある。スクラムマスターは、デイリースクラムを15分間のタイムボックスで終わらせるように開発チームに伝える。
デイリースクラムは開発チームのためのミーティングである。それ以外の人たちが参加する場合、開発チームの邪魔にならないようにスクラムマスターが配慮する。
デイリースクラムは、コミュニケーションを改善し、その他のミーティングを取り除き、開発の障害物を特定・排除し、迅速な意思決定を強調・助長して、開発チームのプロジェクト知識のレベルを向上させるものである。これは、検査と適応の重要なイベントである。
スプリントレビューとは、スプリントの終了時にインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。スプリントレビューでは、スクラムチームとステークホルダーがスプリントの成果をレビューする。スプリントの成果とプロダクトバックログの変更を参考にして、価値を最適化するために次に何ができるかを参加者全員で話し合う。これはステータスミーティングではなく、略式のミーティングである。インクリメントを提示することで、フィードバックや協力を引き出すことを目的とする。
スプリントが1か月の場合、スプリントレビューは最大4時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。スクラムマスターはスプリントレビューが確実に開催されるようにして、参加者には目的を理解してもらうようにする。スクラムマスターは関係者全員にタイムボックスを守るように伝える。
スプリントレビューには、以下の要素が含まれる。
参加者は、スクラムチームと、プロダクトオーナーが招待した重要なステークホルダーである。
プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないものについて説明する。
開発チームは、スプリントでうまくいったこと、直面した問題点、それをどのように解決したかを議論する。
開発チームは、「完成」したものをデモして、インクリメントに対する質問に答える。「完成」の定義にプロダクト機能のリリースが含まれていれば、それらを表示してレビューしてもらう。
プロダクトオーナーは、現在のプロダクトバックログの状況を説明する。（必要であれば）現在の進捗から、可能性のある目標とデリバリーの日程を予測する。
グループ全体で次に何をするべきかを議論し、次のスプリントプランニングに価値のあるインプットを提供できるようにする。
市場やプロダクトの利用状況によって、次に行うべき最も価値の高いことが変更される可能性をレビューする。
次にリリースするプロダクトの機能や性能のスケジュール・予算・可能性・市場をレビューする。
スプリントレビューの成果は、次のスプリントで使用するプロダクトバックログアイテムが含まれた改訂版のプロダクトバックログである。新たな機会に見合うように、プロダクトバックログを全体的に調整することもある。
スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。
スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリントプランニングが始まる前に行う。スプリントが1か月の場合、スプリントレトロスペクティブは最大3時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。スクラムマスターは、このイベントが確実に開催されるようにする。また、参加者に目的を理解してもらうようにする。
スクラムマスターは、このミーティングがポジティブで生産的になるようにする。スクラムマスターは、全員にタイムボックスを守るように伝える。スクラムマスターは、スクラムのプロセスを説明するために、チームメンバーとして参加する。
スプリントレトロスペクティブには、以下の目的がある。
人・関係・プロセス・ツールの観点から今回のスプリントを検査する。
うまくいった項目や今後の改善が必要な項目を特定・整理する。
スクラムチームの作業の改善実施計画を作成する。
スクラムマスターは、次のスプリントが効果的で楽しいものになるように、スクラムチームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう。スプリントレトロスペクティブにおいてスクラムチームは、作業プロセスの改善や「完成」の定義を調整することにより、プロダクトの品質を向上させる方法を計画する。ただし、プロダクトや組織の基準と衝突しないように適切に行う。
スプリントレトロスペクティブが終わるまでに、スクラムチームは次のスプリントで実施する改善策を特定しなければいけない。これらの改善策の実施は、スクラムチーム自体の検査に対する適応になる。改善はいつでも実施可能だが、スプリントレトロスペクティブは検査と適応に集中するための公式な機会である。
スクラムの作成物は、作業や価値を表したものであり、透明性や検査・適応の機会を提供するものである。スクラムで定義された作成物は、全員が共通理解を得るために必要な情報の透明性を最大化するように設計されている。
プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。プロダクトに対する変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログの内容・可用性・並び順に責任を持つ。
プロダクトバックログは決して完成しない。構築の初期段階には、明確でよく理解できている要求が並べられている。その後、プロダクトや使用環境に合わせて進化する。プロダクトバックログは動的であり、適切で競争力のある有用なプロダクトに必要なものを求めて絶えず変化する。プロダクトが存在する限り、プロダクトバックログも存在し続けるのである。
プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正をすべて一覧にしている。プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。プロダクトバックログアイテムには、「完成」時にそれを確認するためのテスト記述も含まれていることが多い。
プロダクトが使用されて価値が増加し、市場からフィードバックを得られると、プロダクトバックログは巨大で包括的な一覧になる。要求の変更は止まらない。プロダクトバックログは生きた作成物である。ビジネス要求、市場の状態、技術の変化などが、プロダクトバックログの変化につながる。
複数のスクラムチームが同じプロダクトの作業をすることがよくある。そうした場合、プロダクトの作業は1つのプロダクトバックログに記述する。また、アイテムを分類するための属性をプロダクトバックログに追加することもある。
プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。プロダクトバックログのリファインメントによって、アイテムのレビューと改訂が行われる。いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメントは、開発チームの作業の10%以下にすることが多い。ただし、プロダクトバックログアイテムはプロダクトオーナーの判断によって、いつでも更新できる。
並び順が上のプロダクトバックログアイテムほど明確で詳細である。明確で詳細であれば、見積りも正確になる。並び順が下のアイテムほど不正確で詳細ではない。今後のスプリントで開発チームが従事するプロダクトバックログアイテムは、スプリントのタイムボックスで「完成」できるようにうまく細分化する。開発チームが1つのスプリントで「完成」できそうなプロダクトバックログアイテムは、スプリントプランニングで選択できる「準備完了（Ready）」の状態になったと見なすことができる。プロダクトバックログアイテムは、上記のリファインメントによって透明性を獲得することが多い。
開発チームは見積りに対して責任を持つ。プロダクトオーナーがトレードオフの理解や選択などについて開発チームに影響を及ぼすこともあるが、最終的な見積りは実際に作業をする人が行う。
いずれかの時点で、ゴールに対する残作業を合計する。プロダクトオーナーは、少なくともスプリントレビューにおいて、この残作業の合計を追跡する。プロダクトオーナーは、前回のスプリントレビュー時点の残作業の合計と比較して、希望する期日までにゴールに到達できるかどうかを評価する。この情報はステークホルダー全員に明らかにする。
進捗の見通しを立てるために、バーンダウン、バーンアップ、累積フローなどのさまざまなプラクティスが使用されている。これらは有用ではあるが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに発生したことだけが、これから先の意思決定に使用できる。
スプリントバックログは、スプリントで選択したプロダクトバックログアイテムと、それらのアイテムをプロダクトインクリメントにして届け、スプリントゴールを達成するための計画を合わせたものである。スプリントバックログは、次のインクリメントに含まれる機能と、その機能を「完成」したインクリメントにして届けるために必要な作業について、開発チームが予想したものである。
スプリントバックログによって、開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている。継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも1つは含めておく。
スプリントバックログは十分に詳細であり、今後も変更される可能性のある計画である。それはデイリースクラムで理解できる程度のものである。開発チームは、スプリントでスプリントバックログを修正する。スプリントバックログはスプリントで創発される。こうした創発が発生するのは、開発チームが計画を実行するなかで、スプリントゴールの達成に必要な作業を学習するからである。
新しい作業が必要になれば、開発チームがスプリントバックログに作業を追加する。作業が完了すれば、残作業の見積りを更新する。計画の要素が不要になれば削除する。スプリントでスプリントバックログを変更できるのは開発チームだけである。スプリントバックログには、開発チームがスプリントで行う作業がリアルタイムに反映される。スプリントバックログは開発チームのものである。
スプリントのいずれかの時点で、スプリントバックログの残作業を合計する。開発チームは、少なくともデイリースクラムにおいて、この残作業の合計を追跡し、スプリントゴールの達成に見通しを立てる。開発チームはスプリントで残作業を追跡し、自分たちの進捗を管理する。
インクリメントとは、これまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックログアイテムを合わせたものである。スプリントの終了時には、新しいインクリメントが「完成」していなければいけない。つまり、インクリメントが動作する状態であり、スクラムチームの「完成」の定義に合っていることを意味する。インクリメントは、完成していて、検査可能なものであり、スプリントの終了時の経験主義を支援するものである。インクリメントは、ビジョンやゴールに向かうステップである。プロダクトオーナーがリリースを決定する／しないにかかわらず、インクリメントは常に動作する状態にしておかなければいけない。
スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。作成物の透明性が不完全であれば、こうした決定には不備があり、価値は低減し、リスクが高まる可能性がある。
スクラムマスターは、プロダクトオーナー、開発チーム、その他の関係者と一緒になって、作成物が完全に透明化されているかを理解する。不完全な透明性に対処するには、いくつかのプラクティスが存在する。スクラムマスターは、そのなかから最適なプラクティスを選択してもらえるように支援する。スクラムマスターは、作成物の検査、パターンの察知、言説の傾聴、期待値と実際値の違いを把握することで、不完全な透明性を検知できる。
スクラムマスターの仕事は、スクラムチームや組織と一緒になって、作成物の透明性を向上させることである。この仕事には、学習・説得・変化を伴うことが多い。透明性は一夜にしてならず。透明性とは長い道のりなのである。
プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の意味を理解しておかなければいけない。スクラムチームによってその意味は大きく異なるかもしれないが、作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。これは、スクラムチームの『「完成」の定義』と呼ばれ、プロダクトインクリメントの作業が完了したかどうかの評価に使われる。
この定義は、開発チームがスプリントプランニングでプロダクトバックログアイテムをいくつ選択するかの指針にもなる。各スプリントの目的は、そのときの「完成」の定義に合ったリリース判断可能な機能のインクリメントを届けることである。
開発チームは、スプリントごとにプロダクトインクリメントを届ける。インクリメントは実際に利用可能なものであり、プロダクトオーナーがすぐにリリースすることもできる。インクリメントの「完成」の定義に関して、開発組織の慣例・標準・ガイドラインが存在する場合は、スクラムチームは最低でもそれを守らなければいけない。
インクリメントの「完成」の定義が開発組織に存在しない場合は、スクラムチームの開発チームはプロダクトに適した「完成」を定義しなければいけない。複数のスクラムチームがシステムやプロダクトのリリース作業をする場合は、すべてのスクラムチームの開発チームが共通の「完成」の定義を使用しなければいけない。
インクリメントは、それまでのインクリメントに追加されたものであり、すべてが正常に動くように十分にテストされたものである。
スクラムチームが成熟していくと、「完成」の定義にさらに厳しい品質条件を追加することもある。新しい定義を作り、それを使用していくと、以前に「完成」したインクリメントにも手を加えなければいけないことが明らかになる可能性がある。あらゆるプロダクトやシステムは「完成」の定義を備えるべきである。それがあらゆる作業の完了基準となる。
スクラムは無料であり、本ガイドで提供されるものである。スクラムの役割・イベント・作成物・ルールは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてをまとめたものがスクラムであり、その他の技法・方法論・プラクティスのコンテナとして機能する。
スクラムに貢献してくれた非常に多くの人たちのなかでも、最初に貢献してくれた人物の名前を挙げたい。まず、Jeff Sutherlandと一緒に働いたJeff McKennaとJohn Scumniotales。それから、Ken Schwaberと一緒に働いたMike SmithとChris Martinと同僚たち。翌年からは、その他にも多くの人たちが貢献してくれた。彼らの助けがなければ、スクラムは今日のように洗練されていなかっただろう。
Ken SchwaberとJeff Sutherlandが1995年からスクラムに取り組み、1995年のOOPSLAカンファレンスにおいて、スクラムを共同発表した。この発表は、KenとJeffが過去数年間で学んだことを文書化したものであり、はじめて公開された正式なスクラムの定義である。
スクラムの歴史は別のところで説明されている。最初の試行錯誤の場であるIndividual, Inc.、Newspage、Fidelity Investments、IDX（現 GE Medical）に感謝したい。
スクラムガイドは、Jeff SutherlandとKen Schwaberが20年以上かけて開発・進化・保守してきたスクラムを文書化したものである。その他の情報源では、スクラムフレームワークを補完するパターン、プロセス、インサイトなどが提供されている。これらは、生産性、価値、創造性、結果に対する満足を高める可能性がある。
本ガイドは、Ken SchwaberとJeff Sutherlandによる英語バージョンを日本語に翻訳したものである。日本語訳は、角征典が担当した。最新版の翻訳は、守田憲司さん、高江洲睦さん、永瀬美穂さん、栗秋宏徳さん、川口恭伸さん、角谷信太郎さん、木村卓央さん、原田騎郎さん、吉羽龍太郎さんにご協力いただいた。以前の版では、むらはしけんいちさん、いろさん、たなべすなおさんにもご協力いただいた。
翻訳に関する連絡先：角征典（kdmsnr@gmail.com）
当初、スクラムはプロダクトの開発と管理のために開発された。1990年代初頭から使用され、今では以下のように世界中で広く利用されている。
有望な市場・技術・プロダクトの研究および特定
プロダクトや追加機能の開発
プロダクトや追加機能のリリース（1日に何度もリリースされる）
プロダクトが使用するクラウド（オンライン、セキュア、オンデマンド）やその他運用環境の開発と保守
プロダクトの保守や刷新
スクラムは、ソフトウェア、ハードウェア、組込みソフトウェア、機能同士を接続するネットワーク、自動運転車などの開発から、学校、政府、マーケティング、組織運営マネジメントに至るまで、個人や社会が日常的に使用するあらゆるものに使用されている。
技術・市場・環境の複雑化やそれらの相互作用は急速に高まっており、スクラムがその対応に有効であることは日々証明されている。
スクラムは反復的で漸進的な知識移転において特に有効であることが示されている。今では、プロダクト、サービス、所属する組織の管理に広く利用されている。
スクラムの本質は、少人数制のチームである。個々のチームは非常に柔軟で適応力に優れている。こうした強みは、単一のチームであっても、複数あるいは多数のチームであっても、数千人の成果やプロダクトを開発・リリース・運用・保守するネットワーク型のチームであっても有効である。チームは協力や情報交換をしながら、洗練された開発アーキテクチャやターゲットとするリリース環境を整えていく。
スクラムガイドで「開発」や「開発する」といった言葉が登場するとき、それは上記のような複雑な作業を意味している。
スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。そのためにスクラムマスターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援する。
スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。
スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるようにする。
デイリースクラムとは、開発チームのための15分間のタイムボックスのイベントである。スプリントでは、毎日デイリースクラムを開催する。開発チームは、次の24時間の作業を計画する。前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をすることで、チームのコラボレーションやパフォーマンスを最適化するのである。デイリースクラムは毎日、同じ時間・場所で開催し、複雑にならないようにする。
デイリースクラムの構成は、開発チームが設定する。スプリントゴールを目指している限り、他のやり方で行なっても構わない。質問を使うチームもあれば、議論ベースで進めるチームもある。たとえば、以下のような例を使用するといいだろう。
・開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？ ・開発チームがスプリントゴールを達成するために、私が今日やることは何か？ ・私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？
「最大」という言葉を追加して、イベントを時間どおりに行なう必要があるのかという疑問を解消し、許容される最大の時間であることを明確にした。
継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも1つは含めておく。
インクリメントは、完成していて、検査可能なものであり、スプリントの終了時の経験主義を支援するものである。インクリメントは、ビジョンやゴールに向かうステップである。
©2017 Ken Schwaber and Jeff Sutherland.
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 summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.