Scrum Guides 2020
本記事の前提
Scrum Guidesの英語版をChatGPT4(以下、ChatGPT)に投げて返ってきた内容を載せています。Scrumを学習したいと思い、原典にあたろうとしているのですが英語が得意じゃないのでChatGPTさんのお力を借りつつ、本来の目的であるScrumの理解を深めようと思っています。
ChatGPTに聞くとおおよそ同じような答えが返ってきますが、毎回聞くのも手間ですし、用語なども追加で聞いていることもあるので備忘録を兼ねて残します。
僕と同じようなScrum初学者の方に参考になれば幸いです。
オリジナルの Scrum Guides(英文)
Home | Scrum Guides
Scrumガイドの目的
1990年代初頭にScrumを開発しました。2010年に最初のScrumガイドを作成したのは、世界中の人々がScrumを理解するのを助けるためです。以来、私たちはガイドを小さな、実用的な更新を通じて進化させてきました。私たちは一緒にこのガイドを支えています。
ScrumガイドにはScrumの定義が含まれています。フレームワークの各要素は、Scrumで実現される全体的な価値と結果にとって本質的な目的を果たします。Scrumのコアデザインや考え方を変える、要素を省略する、またはScrumのルールに従わないと、問題を覆い隠し、Scrumの利点を制限し、最悪の場合は無意味にする可能性があります。
私たちは、ますます複雑な世界でのScrumの使用が増えていくのを見守っています。Scrumのルーツであるソフトウェア製品開発を超えて、本質的に複雑な作業を持つ多くの領域でScrumが採用されていることに、私たちは謙虚に感じています。Scrumの使用が広がるにつれて、開発者、研究者、アナリスト、科学者、その他の専門家が作業を行います。Scrumで「開発者」という言葉を使うのは、排除するためではなく、単純化するためです。Scrumから価値を得ているなら、自分自身を含めて考えてください。
Scrumが使用される中で、この文書で説明されているようなScrumフレームワークに適合するパターン、プロセス、洞察が見つかるかもしれませんし、適用されるかもしれませんし、開発されるかもしれません。それらの説明はScrumガイドの目的を超えています。なぜなら、それらはコンテキストに敏感であり、Scrumの使用方法によって大きく異なるからです。Scrumフレームワーク内でのそのような戦術は広範囲にわたり、他の場所で説明されています。
Scrumの定義
Scrumは、複雑な問題に対する適応的な解決策を通じて、人々、チーム、そして組織が価値を生み出すための軽量なフレームワークです。
簡単に言うと、Scrumはスクラムマスターが以下の環境を育成することを要求します:
- プロダクトオーナーが複雑な問題のための作業をプロダクトバックログに順序付けします。
- スクラムチームが選択された作業をスプリント中に価値のあるインクリメントに変換します。
- スクラムチームとそのステークホルダーが結果を検証し、次のスプリントに向けて調整します。
- これを繰り返します
Scrumはシンプルです。そのまま試し、その哲学、理論、構造が目標達成と価値創造を支援するかどうかを判断してください。Scrumフレームワークは意図的に不完全であり、Scrum理論を実装するために必要な部分だけを定義しています。Scrumはそれを使用する人々の集合知によって構築されています。詳細な指示を人々に提供するのではなく、Scrumのルールは彼らの関係と相互作用を導きます。
フレームワーク内で様々なプロセス、技術、方法が用いられることができます。Scrumは既存の慣行を包み込むか、それらを不必要にします。Scrumは現在の管理、環境、作業技術の相対的な効果を可視化し、改善ができるようにします。
Scrumの理論
Scrumは経験主義とリーン思考に基づいています。経験主義は知識が経験から来て、観察したことに基づいて決定を下すと主張します。リーン思考は無駄を減らし、本質に焦点を当てます。
Scrumは反復的、増分的なアプローチを用いて予測可能性を最適化し、リスクを管理します。Scrumは、作業を行うための全てのスキルと専門知識を持つ人々のグループを参加させ、必要に応じてそのスキルを共有または習得します。
Scrumは、スプリントという包括的なイベント内で、検証と適応のための4つの公式なイベントを組み合わせます。これらのイベントは、透明性、検証、適応という経験主義のScrumの柱を実装するために機能します。
透明性
進行中のプロセスと作業は、作業を行う人々と作業を受け取る人々に見える形でなければなりません。Scrumでは、重要な決定は3つの公式なアーティファクトの認識される状態に基づいています。透明性が低いアーティファクトは、価値を減少させ、リスクを増加させる決定につながる可能性があります。
透明性は検証を可能にします。透明性なしの検証は誤解を招き、無駄になります。
検証
Scrumのアーティファクトと合意した目標に向けた進行状況は、望ましくないバリエーションや問題を検出するために、頻繁かつ厳密に検証しなければなりません。検証を助けるために、Scrumはその5つのイベントの形でリズムを提供します。
検証は適応を可能にします。適応なしの検証は無意味と見なされます。Scrumのイベントは変化を引き起こすように設計されています。
適応
もしプロセスのいずれかの側面が許容範囲を逸脱したり、結果としての製品が受け入れられない場合、適用されているプロセスまたは生産されている素材は調整しなければなりません。調整は、さらなる逸脱を最小限に抑えるために、できるだけ早く行われるべきです。
関与している人々が権限を持っていないか、自己管理していないと、適応は難しくなります。Scrumチームは、検証を通じて新たな知識を得た瞬間に適応することが期待されています。
Scrumの価値観
Scrumの成功した使用は、人々が以下の5つの価値観をより熟達して生きることに依存します:
コミットメント(約束)、フォーカス(集中力)、オープンネス(開放性)、リスペクト(尊重)、カラージュ(勇気)
Scrumチームは、その目標達成と互いの支援にコミットします。彼らの主要な焦点は
スプリントの作業にあり、これらの目標に向けた最善の進行を達成します。Scrumチームとそのステークホルダーは、作業と課題についてオープンです。Scrumチームのメンバーは互いを有能で独立した人々と尊重し、彼らと一緒に働く人々からもそのように尊重されます。Scrumチームのメンバーは、正しいことをする勇気と、厳しい問題に取り組む勇気を持っています。
これらの価値観は、Scrumチームの仕事、行動、行動に対する指針を与えます。行われる決定、取られるステップ、Scrumの使用方法は、これらの価値観を強化し、それらを減少させたり、損なったりするべきではありません。Scrumチームのメンバーは、Scrumのイベントとアーティファクトと一緒に働くことで価値観を学び、探求します。これらの価値観がScrumチームと彼らが働く人々によって体現されると、透明性、検証、適応という経験主義のScrumの柱が生きてくることで信頼を築きます。
Scrumチーム
Scrumの基本単位は、一つの小さなチーム、つまりScrumチームです。Scrumチームは一人のScrumマスター、一人のプロダクトオーナー、およびデベロッパーで構成されています。Scrumチーム内には、サブチームや階層はありません。それは一度に一つの目標、つまりプロダクトゴールに集中する専門家のまとまった単位です。
Scrumチームはクロスファンクショナルであり、つまりメンバーは各スプリントで価値を生み出すために必要な全てのスキルを持っています。また、自己管理型であり、つまり誰が何を、いつ、どのように行うかを内部で決定します。
Scrumチームは、素早く動くことができ、かつスプリント内で重要な作業を完了できるだけの大きさ、通常は10人以下で構成されています。一般的に、小さなチームの方がコミュニケーションが良く、生産性が高いことがわかっています。Scrumチームが大きすぎると感じた場合、同じ製品に焦点を当てた複数のScrumチームに再編することを検討すべきです。したがって、同じプロダクトゴール、プロダクトバックログ、プロダクトオーナーを共有すべきです。
Scrumチームは、ステークホルダーとの協力、検証、保守、運用、実験、研究開発、その他必要なことすべてを含む全ての製品関連活動を担当します。彼らは組織から自己の作業を管理するように構造化され、権限が与えられています。持続可能なペースでのスプリント作業は、Scrumチームの集中力と一貫性を改善します。
全体のScrumチームは、毎スプリントで価値ある、有用なインクリメントを作り出すことに責任を持ちます。ScrumはScrumチーム内で三つの具体的な責任を定義しています: デベロッパー、プロダクトオーナー、Scrumマスター。
デベロッパー
デベロッパーは、Scrumチームの中で毎スプリントで使用可能なインクリメントのあらゆる側面を作成することにコミットメントを持つ人々です。
デベロッパーに必要な具体的なスキルはしばしば広範であり、作業の領域によって異なります。しかし、デベロッパーは常に以下について責任を持ちます:
- スプリントの計画、つまりスプリントバックログの作成;
- 完了の定義に従うことで品質を確保;
- 毎日スプリントゴールに向けて計画を調整; そして、
- プロフェッショナルとして互いに責任を持つこと。
プロダクトオーナー
プロダクトオーナーは、Scrumチームの仕事から得られる製品の価値を最大化することに責任を持ちます。これがどのように達成されるかは、組織、Scrumチーム、個々の人々によって大いに異なります。
また、プロダクトオーナーは効果的なプロダクトバックログの管理に責任を持ち、それには以下が含まれます:
- プロダクトゴールの開発と明確な伝達;
- プロダクトバックログアイテムの作成と明確な伝達;
- プロダクトバックログアイテムの順序付け; そして、
- プロダクトバックログが透明で、見える位置にあり、理解されていることの確保。
プロダクトオーナーは上記の仕事を自分で行うことも、他人に責任を委任することもできます。どちらにせよ、プロダクトオーナーは責任を持ち続けます。
プロダクトオーナーが成功するためには、組織全体が彼らの決定を尊重する必要があります。これらの決定は、プロダクトバックログの内容と順序、そしてスプリントレビューで検査可能なインクリメントを通じて可視化されます。
プロダクトオーナーは一人の人間であり、委員会ではありません。プロダクトオーナーは、プロダクトバックログにおいて多くのステークホルダーのニーズを代表することができます。プロダクトバックログを変更したい人は、プロダクトオーナーを説得することでそれを試みることができます。
Scrumマスター
Scrumマスターは、Scrumガイドに定義された通りにScrumを確立することに責任を持ちます。これを達成するために、ScrumマスターはScrumチームと組織全体がScrumの理論と実践を理解するのを支援します。
ScrumマスターはScrumチームの効果性に責任を持ちます。これを達成するために、ScrumマスターはScrumチームがScrumフレームワーク内でその実践を改善するのを支援します。
Scrumマスターは真のリーダーであり、Scrumチームとより大きな組織をサーブします。
Scrumマスターは、以下のような方法でScrumチームに奉仕します:
- チームメンバーを自己管理とクロス機能性についてコーチングする;
- ScrumチームがDoneの定義を満たす高価値なインクリメントの作成に集中するのを助ける;
- Scrumチームの進行を妨げる障害を除去する; そして、
- すべてのScrumイベントが実施され、ポジティブで生産的であり、時間内に保たれることを確認する。
Scrumマスターは、以下のような方法でプロダクトオーナーに奉仕します:
- 効果的なプロダクトゴール定義とプロダクトバックログ管理のためのテクニックを見つけるのを助ける;
- Scrumチームが明確で簡潔なプロダクトバックログアイテムの必要性を理解するのを助ける;
- 複雑な環境での経験的な製品計画を確立するのを助ける; そして、
- ステークホルダーの協力を要請または必要に応じて促進する。
Scrumマスターは、以下のような方法で組織に奉仕します:
- 組織のScrum採用におけるリーディング、トレーニング、コーチング;
- 組織内のScrum実装の計画とアドバイス;
- 従業員とステークホルダーが複雑な作業のための経験的なアプローチを理解し、実行するのを助ける; そして、
- ステークホルダーとScrumチームとの間の障壁を取り除く。
スクラムのイベント
スプリントはすべての他のイベントを包含するものです。Scrumの各イベントは、Scrumアーティファクトを検査し、適応する正式な機会です。これらのイベントは、必要な透明性を確保するために特別に設計されています。規定された任意のイベントを実行しないことは、検査と適応の機会を失う結果となります。Scrumでは、定期性を作り出し、Scrumで定義されていない会議の必要性を最小限に抑えるためにイベントが使用されます。最適には、すべてのイベントは複雑さを減らすために同じ時間と場所で開催されます。
スプリント
スプリントはScrumの鼓動であり、ここでアイデアが価値に変わります。スプリントは一ヶ月またはそれ以下の固定の長さのイベントで、一貫性を作り出します。新しいスプリントは前のスプリントの終了直後にすぐに始まります。プロダクトゴールを達成するためのすべての作業、すなわちスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブは、スプリントの中で行われます。
スプリントの間には:
- スプリントゴールを危険にさらすような変更は行われません;
- 品質は下がりません;
- 必要に応じてプロダクトバックログが洗練されます; そして、
- もっと学んだことにより、スコープはプロダクトオーナーと明確にされ、再交渉されるかもしれません。
スプリントは、少なくとも毎月一度、プロダクトゴールに向けた進行の検査と適応を確実にすることで予測可能性を提供します。スプリントの視野が長すぎると、スプリントゴールが無効になる可能性があり、複雑さが増し、リスクが増加する可能性があります。より短いスプリントを用いることで、より多くの学習サイクルを生成し、コストと努力のリスクをより短い時間枠に制限することができます。各スプリントは、短期プロジェクトと見なすことができます。
進捗を予測するためのさまざまな方法が存在します。バーンダウンチャート、バーンアップチャート、または累積フローダイアグラムなどです。これらは有用性が証明されていますが、それらは経験主義の重要性を置き換えるものではありません。複雑な環境では、何が起こるかは不明です。既に起こったことだけが、前向きの意思決定のために使用されることができます。
スプリントゴールが陳腐化した場合、スプリントはキャンセルされる可能性があります。スプリントをキャンセルする権限を持つのはプロダクトオーナーだけです。
スプリントプランニング
スプリントプランニングは、スプリントの作業を計画することでスプリントを開始します。この結果となる計画は、Scrumチーム全体の共同作業によって作成されます。
プロダクトオーナーは、参加者が最も重要なプロダクトバックログアイテムとそれらがプロダクトゴールにどのようにマッピングされるかについて話し合う準備ができていることを確認します。Scrumチームは、助言を提供するために他の人々をスプリントプランニングに招待することもあります。
スプリントプランニングは以下のトピックに対応します:
トピック1: なぜこのスプリントは価値があるのか?
プロダクトオーナーは、現在のスプリントで製品がどのようにその価値と利便性を増やすことができるかを提案します。その後、Scrumチーム全体がスプリントゴールを定義し、スプリントがステークホルダーにとってなぜ価値があるかを伝えます。スプリントゴールは、スプリントプランニングの終了前に最終化しなければなりません。
トピック2: このスプリントで何が達成できるのか?
プロダクトオーナーとの議論を通じて、開発者は現在のスプリントに含めるためにプロダクトバックログからアイテムを選択します。Scrumチームはこのプロセス中に
これらのアイテムを洗練することがあり、これにより理解と信頼が増します。
スプリント内で完了できる作業量を選択することは難しいかもしれません。しかし、開発者が自分たちの過去のパフォーマンス、今後のキャパシティ、そして「Doneの定義」についてどれだけ知っているかにより、彼らのスプリント予測に対する自信は増します。
トピック3: 選ばれた作業はどのように行われるのか?
選ばれた各プロダクトバックログアイテムについて、開発者は「Doneの定義」を満たすインクリメントを作成するための作業を計画します。これは、プロダクトバックログアイテムを1日以下の小さな作業アイテムに分解することによってしばしば行われます。これをどのように行うかは、開発者だけが決定することができます。他の誰もが彼らにどのようにプロダクトバックログアイテムを価値のあるインクリメントに変えるかを指示することはありません。
スプリントゴール、スプリントに選ばれたプロダクトバックログアイテム、それらを提供するための計画は一緒にスプリントバックログと呼ばれます。
スプリントプランニングは、一ヶ月のスプリントについては最大8時間までと制限されています。短いスプリントの場合、イベントは通常短くなります。
デイリースクラム
デイリースクラムの目的は、スプリントゴールに対する進捗を検証し、必要に応じてスプリントバックログを調整し、今後の計画された作業を調整することです。
デイリースクラムは、Scrumチームの開発者のための15分間のイベントです。複雑さを減らすために、スプリントの各稼働日に同じ時間と場所で開催されます。もしプロダクトオーナーやスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合、彼らは開発者として参加します。
開発者は、デイリースクラムがスプリントゴールに向けた進捗に焦点を当て、次の日の作業のための実行可能な計画を作り出す限り、彼らが望むどんな構造と技術でも選択することができます。これにより、集中力が向上し、自己管理が改善されます。
デイリースクラムは、コミュニケーションを改善し、障害を特定し、迅速な意思決定を促進し、結果として他のミーティングの必要性を排除します。
デイリースクラムは、開発者が計画を調整する唯一の時間ではありません。彼らは、スプリントの残りの作業の適応や再計画についてより詳細な議論のために、一日を通じてよく会合を持ちます。
スプリントレビュー
スプリントレビューの目的は、スプリントの結果を検証し、未来の適応を決定することです。Scrumチームは、彼らの作業の結果を主要なステークホルダーに提示し、プロダクトゴールに対する進捗を議論します。
このイベントの間、Scrumチームとステークホルダーは、スプリントで何が達成され、彼らの環境で何が変化したかをレビューします。この情報に基づいて、出席者は次に何をすべきかについて協力します。プロダクトバックログも、新たな機会に対応するために調整されることがあります。スプリントレビュ
ーは作業のセッションであり、Scrumチームはプレゼンテーションに限定することを避けるべきです。
スプリントレビューは、スプリントの最後から2番目のイベントであり、一ヶ月スプリントの場合、最大4時間までと制限されています。短いスプリントの場合、このイベントは通常短くなります。
スプリントレトロスペクティブ
スプリントレトロスペクティブの目的は、品質と効果性を高める方法を計画することです。
Scrumチームは、個々の人々、相互作用、プロセス、ツール、そして彼らの「Doneの定義」に関して、最後のスプリントがどのように進行したかを検証します。検証される要素は、作業の領域によってしばしば異なります。彼らを誤った方向に導いた仮定が特定され、その起源が探求されます。Scrumチームは、スプリント中に何がうまくいったのか、どのような問題に遭遇したのか、そしてそれらの問題がどのように(あるいは解決されなかったのか)を議論します。
Scrumチームは、その効果性を向上させるために最も役立つ変更を特定します。最も影響力のある改善は、できるだけ早く取り組まれます。それらは次のスプリントのスプリントバックログに追加されることさえあります。
スプリントレトロスペクティブはスプリントを締めくくります。それは一ヶ月のスプリントについては最大3時間までと制限されています。短いスプリントの場合、このイベントは通常短くなります。
Scrumの成果物
Scrumの成果物は、作業や価値を表します。それらは重要な情報の透明性を最大化するように設計されています。したがって、それらを検証するすべての人が進捗を測るための同じ基準を持つようにします。
各成果物には、透明性を強化し、進捗を測るための焦点を提供する情報を確実にするためのコミットメントが含まれています:
- プロダクトバックログの場合は、プロダクトゴールです。
- スプリント
バックログの場合は、スプリントゴールです。
- インクリメントの場合は、Doneの定義です。
これらのコミットメントは、Scrumチームとそのステークホルダーのための経験主義とScrumの価値を強化するために存在します。
プロダクトバックログ
プロダクトバックログは、製品を改善するために必要なものの緊急性と順序を示したリストです。これはScrumチームが取り組む仕事の唯一の源です。
Scrumチームが一つのスプリントで完了できるプロダクトバックログの項目は、スプリント計画イベントで選択できるとされています。これらは通常、精緻化活動の後にこのレベルの透明性を獲得します。プロダクトバックログの精緻化とは、プロダクトバックログの項目をより小さく、より正確な項目に分割し、詳細化する行為です。これは、説明、順序、サイズなどの詳細を追加するための継続的な活動です。属性は作業の領域によってしばしば異なります。
作業を行う開発者がサイズを決定する責任があります。プロダクトオーナーは、開発者がトレードオフを理解し、選択するのを助けることで、開発者に影響を与えることができます。
コミットメント: プロダクトゴール
プロダクトゴールは、製品の未来の状態を記述し、Scrumチームが計画するための目標となるものです。プロダクトゴールはプロダクトバックログにあります。プロダクトバックログの残りの部分は、プロダクトゴールを達成するための「何」を定義するために現れます。
製品とは価値を提供するための手段であり、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客がいます。製品はサービス、物理的な製品、またはもっと抽象的なものであることもあります。
プロダクトゴールは、Scrumチームの長期的な目標です。彼らは次の目標に取り組む前に、一つの目標を達成(または放棄)しなければなりません。
スプリントバックログ
スプリントバックログは、スプリントゴール(なぜ)、スプリントに選ばれたプロダクトバックログの項目群(何)、そしてインクリメントを提供するための具体
的な計画(どのように)から構成されています。
スプリントバックログは、開発者たちによる計画であり、開発者がスプリントの間にスプリントゴールを達成するために何を達成するつもりかをリアルタイムで可視化するものです。その結果、スプリントバックログはスプリント中に新たな情報が得られるにつれて更新されます。デイリースクラムで進捗状況を検討するのに十分な詳細が必要です。
コミットメント: スプリントゴール
スプリントゴールはスプリントのための唯一の目標です。スプリントゴールは開発者によるコミットメントであり、それを達成するための具体的な作業については柔軟性を持っています。また、スプリントゴールは統一感と焦点を提供し、Scrumチームが一緒に働くことを奨励します、それでは個々のイニシアチブに取り組むのではなく。
スプリントゴールはスプリント計画イベント中に作成され、その後スプリントバックログに追加されます。開発者がスプリント中に働く際には、スプリントゴールを念頭に置いています。作業が予想と異なる場合、彼らはプロダクトオーナーと協力して、スプリントゴールに影響を与えることなくスプリント内でスプリントバックログの範囲を交渉します。
インクリメント
インクリメントは、プロダクトゴールに向けた具体的な一歩です。各インクリメントは、以前のインクリメントすべてに加えられ、厳密に検証され、すべてのインクリメントが一緒に機能することを保証します。価値を提供するためには、インクリメントは使用可能でなければなりません。
スプリントの中で複数のインクリメントが作成されることがあります。インクリメントの総和はスプリントレビューで提示され、経験主義を支持します。しかし、インクリメントはスプリントの終了前にステークホルダーに提供されることもあります。スプリントレビューは、価値をリリースするゲートと見なされるべきではありません。
作業は、「完了の定義」を満たしていなければ、インクリメントの一部とはみなされません。
コミットメント: 完了の定義
完了の定義は、インクリメントが製品に必要な品質基準を満たしたときの状態についての公式な説明です。
プロダクトバックログの項目が完了の定義を満たす瞬間、新たなインクリメントが生まれます。
完了の定義は、インクリメントの一部として完成した作業について全員が共有する理解を提供し、透明性を作り出します。プロダクトバックログの項目が完了の定義を満たしていない場合、それはリリースされることも、スプリントレビューで発表されることもありません。代わりに、それは将来考慮されるためにプロダクトバックログに戻ります。
組織の標準の一部としてのインクリメントの完了の定義は、すべてのScrumチームが最低限遵守しなければなりません。それが組織の標準でない場合、Scrumチームは製品に適した完了の定義を作成しなければなりません。
開発者は完了の定義に従うことが求められます。製品に関して複数のScrumチームが一緒に働いている場合、彼らは共通の完了の定義を相互に定義し、それに従わなければなりません。
エンドノート
Scrumは無料で、このガイドで提供されています。ここで概説されているScrumフレームワークは不変です。Scrumの一部だけを実装することは可能ですが、その結果はScrumではありません。Scrumはその全体性においてのみ存在し、他の技術、方法論、実践のコンテナとして機能します。
謝辞
人々
Scrumに貢献した数千人の中から、最初に重要な役割を果たした人々を特に挙げるべきです:Jeff SutherlandはJeff McKennaとJohn Scumniotalesと共に働き、Ken SchwaberはMike SmithとChris Martinと共に働き、そして彼ら全員が一緒に働きました。その後の数年間で多くの他の人々が貢献し、その助けなしではScrumは今日のように洗練されていなかったでしょう。
Scrumガイドの歴史
Ken SchwaberとJeff Sutherlandは1995年のOOPSLA Conferenceで初めてScrumを共同で発表しました。それは基本的にKenとJeffが過去数年間に得た学びを文書化し、Scrumの最初の正式な定義を公開したものでした。
Scrumガイドは、Jeff SutherlandとKen Schwaberにより30年以上にわたって開発、進化、維持されたScrumを文書化しています。他のソースは、Scrumフレームワークを補完するパターン、プロセス、洞察を提供します。これらは生産性、価値、創造性、結果に対する満足度を高めることができます。
Scrumの完全な歴史は他の場所で記述されています。最初に試され、証明された場所を称えるために、Individual Inc.、Newspage、Fidelity Investments、そしてIDX(現在はGE Medical)を認識します。