驗收標準： 能夠指示使用者故事範圍的細節，並幫助團隊和產品負責人確定是否完成。
敏捷： Scrum 是為更廣泛的理念集合而創造的名稱；敏捷價值和原則體現在以下方面： 敏捷宣言.
建築師： Scrum 團隊中沒有架構師的角色，所有團隊成員都負責建立架構。
燃燒殆盡： （請參閱報告部分的衝刺燃盡圖、產品燃盡圖）。
待辦事項整理： （請參閱「故事時間」。也稱為梳理和待辦事項梳理。）
待辦事項： （請參閱產品待辦事項）
雞： （古語）指不在團隊中的任何人，該詞冒犯了一些人，因此現在很少使用，參見“豬”。
每日站會： 每天進行15分鐘的團隊會議，分享進度、報告遇到的問題並做出承諾。在每日站會上，每位團隊成員都要回答三個問題：
- 「從上次 Scrum 會議（即昨天）到現在，我做了些什麼？”
- 「在下次 Scrum 會議之前（也就是今天），我要做什麼？”
- “是什麼阻礙了我以最高效的方式完成工作？”
Scrum Master 負責確保所有參與者就任何超出規則範圍的討論召開臨時會議。 Scrum 文獻建議此類會議應在所有團隊成員到齊後，於清晨第一時間召開。
完成： 該術語也稱為“完成”，用於描述被認為可能可以發布的產品增量；這意味著所有設計、編碼、測試和文件都已完成，並且該增量已完全整合到系統中。
出現： 最佳設計和最佳工作方式是在實踐中逐漸形成的原則，而不是預先定義的，參見經驗主義、自組織。
經驗主義： 「檢查和適應」原則允許團隊或個人嘗試某些事情，並透過有意識的反思和改變從經驗中學習，參見湧現、自組織。
史詩： 史詩級使用者故事通常指規模非常大的使用者故事，最終會被拆分成更小的故事；它通常用作尚未完全構思的新想法的佔位符。只要優先順序不是很高，創建史詩級使用者故事本身並沒有錯。
估計： 團隊共同商定產品待辦事項清單中各個使用者故事的規模度量標準的過程。通常使用計劃撲克來完成。
斐波那契數列： 在這個數字序列中，下一個數字是透過將前兩個數字相加得到的（1,2,3,5,8,13,20…）；該序列的特點是隨著數字的增加，每個間隔都會變大；該序列經常用於故事點數，因為在處理史詩級故事時，估算總是不太準確。
怎麼樣： 「如何做」是一個用來描述團隊領域的術語，與產品負責人的「做什麼」不同。也可以描述為策略（即如何贏得戰鬥）。
障礙： 任何阻礙團隊發揮潛能的因素（例如椅子不舒服）都應納入考量。如果是組織層面的問題，則由 Scrum Master 負責消除；如果是團隊內部的問題，則應由團隊成員自行解決。
障礙積壓： 一份可見或不可見的障礙清單，依其對團隊生產力造成的阻礙程度，依優先順序排序。
豬： （古體）指團隊成員，該詞冒犯了一些人，因此現在很少使用，參見“chicken”。
日程安排： 參見衝刺計劃
計劃撲克： 一款用於對故事進行估算的遊戲；它採用德爾菲法達成共識。
過程： 這只是每個人的工作方式。每個人都有自己的工作流程。它可以是預先設定的，也可以是經驗性的，或者只是混亂的。
產品待辦事項： 一份按優先順序排序的待處理故事清單。
產品待辦事項： 產品待辦事項清單（或簡稱「待辦事項」）是系統需求的集合，以優先順序排序的產品待辦事項清單的形式呈現。這些需求包括功能性和非功能性的客戶需求，以及技術團隊所提出的需求。雖然產品待辦事項清單的輸入來源眾多，但產品負責人全權負責決定產品待辦事項的優先順序。 衝刺計劃 會議中，根據產品負責人的優先級，將產品待辦事項從產品待辦事項清單移至迭代周期中。
產品待辦事項： 待辦事項清單中的任何項目，包括使用者故事、史詩，以及可能用於處理技術債等的技術故事。
產品負責人： 產品負責人負責制定產品願景，並維護、確定優先順序和更新產品待辦事項清單。在 Scrum 中，產品負責人擁有最終決定權，代表客戶利益決定待辦事項清單的優先順序和需求問題。產品負責人必須隨時為團隊提供支持，尤其是在迭代計劃會議和迭代評審會議期間。
產品負責人面臨的挑戰：
- 克制住「管理」團隊的衝動。團隊的自組織方式可能與你的預期有所不同。如果有些團隊成員要求你介入本應由團隊自行解決的問題，這一點尤其具有挑戰性。
- 在衝刺階段已經開始後，要抵抗住增加更重要工作的誘惑。
- 在衝刺計畫會議上勇於做出艱難的選擇。
- 平衡各方利害關係人的利益。
相對估計： 透過將待辦事項按相對大小範圍分組，而不是按絕對單位（例如，小時）分組，來確定其大小。參見斐波那契數列和T卹尺寸。
Release: 將開發團隊開發出的潛在可交付產品增量過渡到客戶日常使用中。 Release當一個或多個迭代周期後，產品的價值足以抵消部署成本時，這種情況通常會發生。
Release 燃盡圖： 一個可視化的圖表，用於展示版本發布進度。
回顧： 團隊和 Scrum Master 會共同反思流程，並承諾改進。
羅馬投票： 請查看按讚數。
Scrum Master 的角色： Scrum Master 是團隊和產品負責人的協調者。 Scrum Master 並非直接管理團隊，而是透過以下方式協助團隊和產品負責人：
- 消除開發團隊和產品負責人之間的障礙，使產品負責人能夠直接推動開發。
- 教導產品負責人如何透過 Scrum 實現投資報酬率最大化 (ROI) 並達成目標。
- 透過促進創造力和賦能來改善開發團隊的生活。
- 盡一切可能提高開發團隊的效率。
- 改進工程實踐和工具，使每個功能增量都有可能發布。
- 及時更新團隊進展訊息，並確保所有相關方都能看到這些資訊。
資源： 敏捷專案管理與 Scrum肯·施瓦伯
Scrum 會議： 故事時間、計畫、回顧、總結、每日站會。
Scrum角色： 只有三個角色：產品負責人、Scrum主管、團隊成員。
自組織： 最了解工作的人最知道如何完成工作的原則是，設定明確的目標和界限，讓他們做出所有戰術和實施決策，參見湧現、經驗主義。
穗： 一項簡短、限時的研究，通常是技術性的，針對單一故事，旨在提供足夠的信息，以便團隊能夠估算故事的規模。
短跑： 限時迭代。
衝刺待辦事項： 定義了衝刺的工作內容，包括為實現衝刺目標必須完成的一組任務，以及選定的產品待辦事項。
衝刺消耗： 每日顯示衝刺中剩餘工作量的可視化圖表。
短跑： 目標（又稱衝刺主題）；單一衝刺階段工作的關鍵重點。
衝刺計畫： 團隊與產品負責人召開會議，規劃迭代並就承諾事項達成協議。
衝刺任務： 一項小小的工作，它幫助某個特定故事得以完成。
故事： 待辦事項通常使用範本形式：作為[使用者]，我想要[功能]以便[業務價值]，請參閱產品待辦事項。
利害關係人： 有時以下術語可以互換使用——儘管應該注意的是，它們的定義之間存在細微差別：故事、使用者故事、技術使用者故事、產品待辦事項、PBI 和產品需求。
故事重點： 故事點數是衡量故事大小的單位，參見斐波那契數列、T卹尺寸、2的冪次方等，也是分配故事點數的另一種方式。
講故事的時間： 定期工作會議，討論、改進和估算待辦事項，並對待辦事項進行精簡和優先排序。
任務： 參見衝刺任務。
任務清單： 完成衝刺中承諾的一系列使用者故事所需的任務。
任務板： 一張牆圖，上面貼著卡片和便條，代表團隊在特定迭代周期內的所有工作；任務便籤會在牆上移動，以顯示進度。
球隊： 一個團隊（或「敏捷開發團隊」）的最佳組成人數為七人，上下浮動兩人，負責承諾工作、交付成果，並從戰術角度推動產品向前發展。
軟體開發專案的團隊成員通常由軟體工程師、架構師、程式設計師、分析師、品質保證專家、測試人員、使用者介面設計師等組成，這通常被稱為「跨職能專案團隊」。敏捷實踐也鼓勵跨職能團隊成員。
在迭代衝刺期間，團隊會進行自組織以達成衝刺目標。團隊擁有自主權，可以選擇最佳方式來實現目標，並為此負責。 Scrum Master 扮演守護者的角色，確保團隊與產品負責人保持隔離。 Scrum 也提倡將所有團隊成員集中在一個團隊會議室辦公。
隊員： 團隊成員是指參與衝刺任務並朝著衝刺目標努力的任何人。在 Scrum 術語中，產品負責人 (PO) 和 Scrum Master (SM) 如果也參與開發工作，也可以被視為團隊成員。
豎起大拇指： 快速點頭表示團隊對某項決定的承諾或共識程度。豎起大拇指通常表示同意、是或好，豎起大拇指向下表示不同意、否或壞；模擬版本允許拇指放在半圓上的任何位置，以表示不同程度的同意。
時間盒： 為每項活動設定持續時間，並使其嚴格按照設定的持續時間進行（即會議和衝刺都不會延長——永遠不會）。
速度： 團隊完成工作的速度，通常以故事點數來衡量。在 Scrum 中，速度是指團隊在一個迭代週期內能夠處理多少產品待辦事項。這可以透過查看先前的迭代周期來估算，前提是團隊組成和迭代周期保持不變。也可以使用基於承諾的計劃，逐一迭代週期地確定速度。
一旦確定了速度，就可以利用速度來規劃項目，並預測發布和產品完成日期。
當待辦事項估算故意留有餘地時，速度計算如何才能有意義？大數定律往往會平均掉估算的粗糙度。
願景聲明： 對產品的進階描述，包括目標使用者、必要性以及與類似產品的差異。
什麼： 「做什麼」一詞用來描述產品負責人的領域，與團隊的領域不同，請參閱「怎麼做」。也可以描述為策略（即最佳的行動順序是什麼）。
XP實踐： 一系列開發實踐，包括配對程式設計、測試驅動開發 (TDD) 和持續重構，均源自極限程式設計 (XP) 方法論；許多 Scrum 團隊發現這些實踐大大提高了生產力和團隊士氣。
