スクラム (ソフトウェア開発)
歴史
1986年に野中郁次郎と竹内弘高が「新製品開発のプロセス」について日本の組織とNASAといったアメリカの組織との比較、分析を行った研究論文「The New New Product Development Game」が『ハーバード・ビジネス・レビュー』に掲載される。その中で柔軟で自由度の高い日本発の開発手法をラグビーのスクラムに喩えて「Scrum（スクラム）」として紹介した。
野中、竹内の論文に着想を得たJeff Sutherland、John Scumniotales、Jeff McKenna が、1993年にラウンドトリップ・エンジニアリング（一種の反復型開発）を取り入れたオブジェクト指向プログラミング設計・分析ツールを構築し、実践したのがソフトウェア開発手法としてのスクラムの最初である。当時、素早い開発が求められており、要求仕様を簡単に動作するコードに変換する方法が求められていた。同じころ、ケン・シュエイバーが自社 (ADM) でのソフトウェア開発にこの手法を用いた。スクラムは産業界での様々なベストプラクティスに基づいており、それらがソフトウェア開発手法としてのスクラムの元となった。
このプラクティスは2003年に『アジャイルソフトウェア開発スクラム』としてまとめられた。
プロジェクト区分
プロジェクトは最長4週間の期間に分割される。一つの期間をスプリント（Sprint）と呼び、スプリントごとに実装すべきバックログが入力となる。
工程
スクラムの開発工程は主に6つの活動からなる。「計画ミーティング」、「製品基準の調整・レビュー・配布」、「スプリント」、「スプリントレビュー」、「振り返り」、「クロージャ」である。このうち、計画ミーティング・スプリント・スプリントレビュー・振り返りが繰り返し行われる。
計画ミーティング
プロダクトオーナーは、スプリントで実現させたいプロダクトバックログを、優先順位を伴って確定する。このとき、プロダクトオーナーは、チームに対して、プロダクトバックログの消化数を強制することはできない。これまでのチームのパフォーマンス（ベロシティ・前回スプリントで達成したプロダクトバックログの相対見積り合計）から、どの程度のプロダクトバックログが消化できそうかとを予測するうえでの参考とし、より大きなチーム運営として取り組むためのフィードバックとする（例：今より早く製品を仕上げていくには、チームに人員を追加する）。
チームは、プロダクトバックログの相対見積りを行う。プロダクトオーナーは、プロダクトバックログを勝手に見積もってはならない。また、チームは、プロダクトバックログの優先順位を勝手に変更してはならない。プロダクトバックログの見積りが非現実的と思われる場合、あるいは優先順位についての知見がある場合、プロダクトオーナーは、プロダクトバックログについて、チームに説明する必要がある。プロダクトオーナーは、そのフィードバックを元に、最終的なバックログを決定し、チームと合意する。
プロダクトバックログに対する決定のほかに、スプリント終了時に達成するスプリントゴールを定める。ゴールは、プロダクトと直接関係のない内容でも構わない。チームを改善するあらゆる取り組みを対象とする（例：継続インテグレーション可能な環境を整える・外部ライブラリの使用方法について、チーム内で共有する）。
スプリント
スプリントは、実際にソフトウェア開発が行われる工程である。スプリントは、開発、まとめ、レビュー、調整の繰り返しである。
スプリント内では、決まった順序は存在しない。必要に応じて、バックログの項目を開発し、まとめ、レビューする。また、項目によっては、単にレビューと調整だけで済む場合もある。どのように開発されるかは、そのバックログ項目の内容による。通常は、1週間から4週間のタイムボックスが設定される。
スクラム会議
スプリント期間中、チームは、毎日スクラム会議を開く。スクラム会議は、平日の決まった時間に決まった場所で行う。また、15分以内で完了させなければならない。また、スクラムマスターは、必ず出席しなければならず、チーム全員に対して、「前回のスクラム会議以降、何をしたか」「問題はあるか」「次回のスクラム会議までに何をするか」などの質問をする。会話は、これらの質問への応答に限られる。その質疑応答の結果によっては、即座に別の会議を開くこともある。問題があると報告された場合、スクラムマスターは、即座に意思決定する責任を負う。問題が外的要因によるものである場合、スクラムマスターが、その解決の責任を負う。
スプリントレビュー
スプリントの後には、必ずスプリントレビューが行われる。スプリントレビューでは、スプリントで開発されたソフトウェアのレビューが行われ、必要に応じて、新たなバックログ項目が追加される。また、このレビューには、顧客、マネージャ、開発者が参加する。なお、場合によっては、営業やマーケティング関係者も参加する場合もある。
スプリントとスプリントレビューの繰り返しは、製品の機能や品質が十分であると顧客が判断するまで繰り返される。その後、クロージャ（終了）工程へと移行し、リリースの準備が行われる。
振り返り
振り返りでは、スプリントゴールの達成度、スプリントで発生した問題、その問題に対する改善策などについて話し合う。また、次回のスプリントゴール目標についての取りまとめを行う場合がある。
クロージャ（終了）
クロージャでは、最終的なデバッグ、マーケティング、販売促進を行う。
クロージャの完了をもって、プロジェクトは終了する。ソフトウェア開発の予測は困難であるため、完了が予定より遅くなったり、早まったりすることもある。しかし、スクラムによる制御（後述）を行うことで、その遅延を計算できる。