合否基準： ユーザー ストーリーの範囲を示し、チームと製品の所有者が完了を判断するのに役立つ詳細。
アジャイル： スクラムを含む幅広いアイデアの集合を表す造語。アジャイルの価値と原則は、 アジャイルマニフェスト.
アーキテクト： スクラム チームにはアーキテクトの役割はなく、代わりにチーム メンバー全員がアーキテクチャの作成に責任を負います。
バーンダウン: (レポート セクションのスプリント バーンダウン、製品バーンダウンを参照してください)。
バックロググルーミング: （「ストーリータイム」を参照してください。グルーミングやバックログリファインメントとも呼ばれます。）
バックログ項目: （製品バックログ項目を参照）
チキン： (古語) チームに所属していない人を指す用語。この用語は一部の人々を不快にさせたため、現在ではほとんど使用されていない。Pig を参照。
デイリースクラム: 毎日15分間のチームミーティングで進捗状況を共有し、問題点を報告し、コミットメントを表明します。デイリースクラムでは、各チームメンバーが以下の3つの質問に答えます。
- 「前回のスクラムミーティング以降、何をしましたか？（つまり昨日）」
- 「次のスクラムミーティング（今日）までに何をすればいいですか？」
- 「私の仕事を最大限に効率的に遂行するのを妨げているものは何ですか？」
スクラムマスターは、参加者がこれらの制約から大きく逸脱する議論が発生した場合に、サイドバーミーティングを招集するよう徹底します。スクラムの文献では、このミーティングはチームメンバー全員が到着したらすぐに、朝一番に開催することが推奨されています。
完了： 「完了」とも呼ばれるこの用語は、リリース可能であると考えられる製品の増分を表すために使用されます。つまり、すべての設計、コーディング、テスト、およびドキュメント化が完了し、増分がシステムに完全に統合されていることを意味します。
出現: 最良の設計や最良の作業方法は、事前に定義されるのではなく、時間をかけて作業を行うことで生まれるという原則。経験主義、自己組織化を参照。
経験主義： 「検査と適応」の原則。チームや個人が何かを試し、意識的な反省と変化によって経験から学ぶことを可能にします。創発、自己組織化を参照。
大作： 非常に大規模なユーザーストーリーで、最終的には小さなストーリーに分割されます。エピックは、十分に検討されていない新しいアイデアの仮置きとしてよく使用されます。優先度が高くない限り、エピックを作成しても問題ありません。
推定： プロダクトバックログ内のストーリーの規模について合意するプロセス。チームによって行われ、通常はプランニングポーカーが用いられる。
フィボナッチ数列: 次の数字が前の 2 つの数字を加算して得られる数字のシーケンス (1、2、3、5、8、13、20…)。シーケンスでは、数字が増加するにつれて各間隔の品質が大きくなります。このシーケンスは、ストーリー ポイントでよく使用されます。これは、エピックを扱う場合、見積りが常に不正確になるからです。
どうやって： 「どのように」は、チームの領域を説明するために使用される用語であり、「何を」とは異なり、プロダクト所有者にとって重要です。また、戦術（つまり、戦いに勝つ方法）として説明することもできます。
障害： チームの潜在能力発揮を妨げるもの（例えば、椅子が座り心地が悪いなど）があれば、スクラムマスターはそれを排除する責任があります。チーム内部の問題であれば、スクラムマスター自身が排除すべきです。
障害のバックログ: チームの生産性をどの程度阻害しているかに応じて優先順位をつけた、目に見えるまたは目に見えない障害のリスト。
豚： (古語) チームメンバーを指す用語。この用語は一部の人々を不快にさせたため、現在ではほとんど使用されていない。「チキン」を参照。
計画： スプリント計画を参照
プランニングポーカー: ストーリーに見積もりを適用するために使用されるゲーム。合意に達するためにデルファイ法を使用します。
プロセス： 単に誰かの働き方です。誰もがプロセスを持っています。それは事前に定義されたもの、経験に基づいたもの、あるいは単に混沌としたものかもしれません。
製品バックログ: 作業待ちのストーリーの優先順位リスト。
製品バックログ: プロダクトバックログ（または「バックログ」）とは、システムに対する要件であり、優先順位付けされたプロダクトバックログ項目のリストとして表現されます。これには、機能要件と非機能要件の両方の顧客要件、そして技術チームが作成した要件が含まれます。プロダクトバックログには複数の入力項目がありますが、プロダクトバックログの優先順位付けはプロダクトオーナーの唯一の責任です。 スプリント計画 会議では、プロダクト所有者の優先順位に基づいて、バックログ項目がプロダクト バックログからスプリントへ移動されます。
製品バックログ項目: バックログ リストに含まれる任意の項目。これには、ユーザー ストーリー、エピック、場合によっては技術的負債に対処するための技術ストーリーなどが含まれます。
プロダクトオーナー： 製品のビジョンを持ち、プロダクトバックログの維持、優先順位付け、更新に責任を負う人物。スクラムでは、プロダクトオーナーはバックログの優先順位付けや要件に関する質問において顧客の関心を代表し、最終的な権限を持ちます。この人物はチームにいつでも対応できなければなりませんが、特にスプリント計画会議とスプリントレビュー会議には対応する必要があります。
プロダクトオーナーとしての課題:
- チームを「管理」したいという誘惑に抵抗しましょう。チームは、あなたが期待するような自己組織化をしないかもしれません。特に、チームメンバーの一部が、チーム自身で解決すべき問題に関してあなたの介入を求めてきた場合は、なおさら困難です。
- スプリントがすでに進行中の後に、さらに重要な作業を追加したいという誘惑に抵抗します。
- スプリント計画会議中に難しい選択を進んで行う。
- 競合する利害関係者の利益のバランスをとること。
相対推定: バックログ項目のサイズを、絶対的な単位（例：時間）ではなく、相対的なサイズ範囲でグループ化することで決定します。フィボナッチとTシャツのサイズを参照してください。
Release: 出荷可能な製品の増分を開発チームから顧客による日常的な使用に移行します。 Release通常、これは 1 つ以上のスプリントで製品の価値が展開コストを上回るようになったときに発生します。
Release バーンダウン チャート: リリースに向けた進捗状況を示す目に見えるチャート。
ふりかえり： チームとスクラムマスターがプロセスを振り返り、改善に取り組むセッション。
ローマの投票: 親指投票を参照してください。
スクラムマスターの役割: スクラムマスターは、チームとプロダクトオーナーのファシリテーターです。チームを管理するのではなく、スクラムマスターはチームとプロダクトオーナーの両方を以下の方法で支援します。
- 開発チームとプロダクト オーナー間の障壁を取り除き、プロダクト オーナーが直接開発を推進できるようにします。
- 投資収益率 (ROI) を最大化し、スクラムを通じて目標を達成する方法をプロダクト オーナーに教えます。
- 創造性と権限委譲を促進することで開発チームの生活を向上させます。
- あらゆる方法で開発チームの生産性を向上させます。
- 機能の各増分が出荷可能になるように、エンジニアリングのプラクティスとツールを改善します。
- チームの進捗状況に関する情報を最新の状態に保ち、関係者全員が閲覧できるようにします。
出典： スクラムによるアジャイルプロジェクト管理ケン・シュワバー
スクラムミーティング: ストーリータイム、計画、レビュー、振り返り、デイリースクラム。
スクラムの役割: プロダクトオーナー、スクラムマスター、チームメンバーの3つだけです。
自己組織化: 仕事に最も近い人が仕事のやり方を最もよく知っているので、明確な目標と境界を設定し、彼らにすべての戦術的および実施上の決定を行わせるという原則。cf. 出現主義、経験主義。
スパイク： チームがストーリーの規模を見積もるのに十分な情報を提供することを目的とした、単一のストーリーに関する、通常は技術的な、短い時間枠のリサーチ。
スプリント： 時間制限のある反復。
スプリントバックログ: スプリントの目標を実現するために完了する必要がある一連のタスクと選択された製品バックログ項目によって表されるスプリントの作業を定義します。
スプリントバーンダウン: スプリント内の残りの作業量を毎日示す目に見えるチャート。
スプリント： 目標、別名スプリント テーマ。単一のスプリントにおける作業の主要な焦点。
スプリント計画: スプリントを計画し、コミットメントに関する合意に達するための、チームとプロダクトオーナー間の会議。
スプリントタスク: 特定のストーリーが完了するまで役立つ、単一の小さな作業項目。
ストーリー： バックログ項目は通常、テンプレート形式を使用します: [ユーザー] として、[機能] を [ビジネス価値] になるようにしたい (製品バックログ項目を参照)。
利害関係者: ストーリー、ユーザー ストーリー、テクニカル ユーザー ストーリー、製品バックログ項目、PBI、製品要件などの用語は同義語として使用されることがありますが、定義には微妙な違いがあることに注意する必要があります。
ストーリーポイント: ストーリーのサイズに適用される測定単位。フィボナッチ数列、T シャツのサイズ、2 の累乗など、ストーリー ポイントを割り当てる他の方法もあります。
お話の時間： バックログの項目について議論、改良、見積もりを行い、バックログを削減して優先順位を付ける定期的な作業セッション。
課題・テーマ： スプリントタスクを参照してください。
タスクリスト: スプリントにコミットされた一連のストーリーを完了するために必要なタスク。
タスクボード： 特定のスプリントにおけるチームのすべての作業を示すカードと付箋が付いた壁掛けチャート。タスクのメモはボード上で移動され、進捗状況を表示します。
チーム： チーム (または「スクラム開発チーム」) は、最適には 7 人前後の人数で構成され、戦術的な観点から作業のコミット、製品の提供、製品の推進に責任を持ちます。
ソフトウェア開発プロジェクトでは、チームメンバーは通常、ソフトウェアエンジニア、アーキテクト、プログラマー、アナリスト、QAエキスパート、テスター、UIデザイナーなどで構成されます。これはしばしば「クロスファンクショナル・プロジェクトチーム」と呼ばれます。アジャイルプラクティスでも、クロスファンクショナル・チームメンバーの活用が推奨されています。
スプリント中、チームはスプリントの目標を達成するために自己組織化します。チームは目標達成のための最適な方法を選択する自主性を持ち、その責任を負います。スクラムマスターは、チームがプロダクトオーナーから独立していることを保証する保護者のような役割を果たします。また、スクラムではチーム全体を一つのチームルームに集めることを推奨しています。
チームメンバー: チームメンバーとは、スプリント目標達成に向けてスプリントタスクに取り組む人を指します。スクラム用語では、POとSMも開発に携わっている場合はチームメンバーとなる場合があります。
親指投票: チームの取り組みや決定に対する同意などについて、チームの状況を把握するための素早いパルスです。親指を立てると、一般的に同意、はい、または良いを意味し、親指を下にすると反対、いいえ、または悪いを意味します。このアナログ版では、親指を半円上のどこにでも置くことができ、さまざまな同意の度合いを示すことができます。
タイムボックス: すべてのアクティビティに期間を設定し、その期間だけ正確に継続します (つまり、会議もスプリントも決して延長されません)。
速度： チームが作業を完了する速度。通常はストーリーポイントで測定されます。スクラムでは、ベロシティとは、チームが1スプリントで処理できるプロダクトバックログの作業量を指します。これは、チーム構成とスプリント期間が一定であると仮定した場合、過去のスプリントを参照することで推定できます。また、コミットメントベースの計画を用いて、スプリントごとに設定することもできます。
速度が確立されると、それを使用してプロジェクトを計画し、リリース日と製品の完了日を予測できるようになります。
バックログ項目の見積りが意図的に大まかである場合、速度の計算はどのように意味を持ちますか? 大数の法則により、見積りの大まかさが平均化される傾向があります。
ビジョンステートメント: 製品の概要説明。対象者は誰か、なぜ必要なのか、類似製品との違いは何かなどが含まれます。
内容： 「何を」とは、プロダクトオーナーの領域を表す用語であり、チームにとっては「どのように」とは異なります。また、「戦略」（例えば、戦闘の最善の順序）とも表現されます。
XP プラクティス: XP 方法論から引き出された、ペアプログラミング、テストファースト、テスト駆動開発 (TDD)、継続的なリファクタリングなどの開発プラクティスのセット。多くのスクラム チームは、これらのプラクティスによって生産性とチームの士気が大幅に向上すると考えています。
