XP 盡可能使用被廣泛接受的詞彙。只有當 XP 中的概念與別處顯著不同時，才用新詞來凸顯差異。

以下是 XP 詞彙表中最重要的字。

角色#

• 程式設計師（Programmer）——團隊中負責分析、設計、測試、寫程式與整合的角色。
• 客戶（Customer）——團隊中負責選擇「系統必須滿足哪些故事」、「哪些故事需要先做、哪些可以延後」，以及定義測試以驗證故事正確運作的角色。
• 教練（Coach）——團隊中負責觀察整體流程、並喚起團隊注意即將到來的問題或改善機會的角色。
• 追蹤者（Tracker）——團隊中負責用數字度量進度的角色。
• 管理者（Manager）——團隊中負責分配資源的角色。
• 夥伴（Partner）——與你一起結對寫程式的另一個人。

規劃#

• 規劃遊戲（Planning Game）——XP 的規劃流程。業務端指定系統需要做什麼；開發端指定每項功能的成本，以及每日／每週／每月可用的預算。
• 故事（Story）——客戶想讓系統做的一件事。故事的估算應落在一到五個理想程式設計週之間，而且必須可測試。
• 工程任務（Engineering task）——程式設計師知道系統必須做的一件事。任務的估算必須落在一到三個理想程式設計日之間。多數任務直接衍生自故事。
• 發布（Release）——一疊合起來在業務上說得通的故事。
• 承諾時程（Commitment schedule）——一個發布加上一個日期。承諾時程一次一個迭代地被精煉，並透過重新估算與復原來修改。
• 迭代（Iteration）——一到四週的期間。期初客戶選擇本次迭代要實作的故事；期末客戶可以跑自己的功能測試，看這次迭代是否成功。
• 迭代計畫（Iteration plan）——一疊故事加一疊任務。程式設計師認領任務並估算它們。
• 復原（Recovery）——一個規劃動作：客戶為了保住發布的完成日期，因應「估算增加」或「團隊速度下降」而縮減發布範圍。
• 重新估算（Reestimation）——一個規劃動作：團隊重新估算發布中所有剩餘的故事。

估算與度量#

• 理想程式設計時間（Ideal programming time）——一種估算戰術的度量，做法是問自己：「如果沒有干擾與災難，這要花多久？」
• 負載係數（Load factor）——量測到的「理想程式設計時間」與「日曆時間」之比值，通常介於 2 到 4 之間。
• 團隊速度（Team speed）——團隊在給定時間內能產出的理想程式設計週數。

開發階段#

• 探索（Exploration）——客戶大致溝通「系統整體可以做什麼」的開發階段。
• 正式運行（Production）——客戶真的在用這套系統賺錢的開發階段。

技術實踐#

• 結對程式設計（Pair programming）——兩個人用一組鍵盤、一隻滑鼠、一台螢幕寫程式的技術。在 XP 中，配對通常一天更換數次。
• 重構（Refactoring）——對系統所做的、不改變其行為、但增進某項非功能性品質（簡單性、彈性、可理解性、效能）的變更。
• 系統隱喻（System metaphor）——一個關於「系統如何運作」的故事，讓每個人——客戶、程式設計師與管理者——都能講出來。

測試#

• 自動化測試（Automated test）——無需任何人為介入即可執行的測試案例。測試會檢查系統是否算出預期的值。
• 測試案例（Test case）——一組給系統的自動化刺激與回應。每個測試案例都應該讓系統回到它原本的狀態，這樣測試才能彼此獨立地執行。
• 單元測試（Unit test）——從程式設計師視角寫出的測試。
• 功能測試（Functional test）——從客戶視角寫出的測試。

其他#

• 熵（Entropy）——系統隨時間越來越多 bug、且變更變得昂貴許多的傾向。