自己組織化

チームが外部から細かな指示を受けずに、目標の達成に向けて作業の進め方や役割分担を自分たちで決めて動くこと。アジャイルソフトウェアの12の原則で、最良のアーキテクチャ・要求・設計は自己組織的なチームから生まれるとされる。スクラムガイド2020では自己管理型（self-managing）という表現に改められた。

2001年に軽量な開発手法の提唱者たちがまとめた、アジャイル開発の価値観を示す宣言。プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を価値とする。あわせて12の原則が示されている。

一定期間の活動を終えた節目に、チームでやり方を振り返り、良かった点や問題点を共有して次の期間の改善策を決める活動。アジャイル開発では反復ごとに行い、KPTなどの手法を使う。スクラムではスプリントレトロスペクティブとして行う。

スクラムで開発を担う、プロダクトオーナー1人、スクラムマスター1人、複数の開発者からなる小規模なチーム。チーム内に階層を設けず、プロダクトの価値を高めるために必要な作業を自ら管理して進める。

システム開発を要件定義、設計、実装、テスト、運用などの工程に分け、上流の工程から下流の工程へ順に進める開発モデル。各工程の成果物を確定させてから次の工程に進むので、進捗と品質を管理しやすいが、後の工程で要件の誤りや変更が分かると手戻りが大きい。要件が明確で変更の少ない開発に向く。

利用者にとって価値のある小さな機能（フィーチャー）を単位として、短い周期で設計と実装を繰り返すアジャイル開発の手法。全体のモデルの作成、フィーチャーの一覧の作成、フィーチャーごとの計画、設計、実装の5つの活動で進め、進捗をフィーチャーの完成の度合いで管理する。

アジャイル開発のプロジェクトの開始時に、目的、範囲、優先順位、リスク、体制などを「我々はなぜここにいるのか」などの10の問いに答える形で整理し、関係者の認識をそろえるための資料。プロジェクトの途中でも見直して、目的や前提のずれを確かめるのに使う。