スクラムガイド2013

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