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