正如Scrum 指南中 所述，Scrum 框架由 Scrum 團隊及其相關角色、事件、工件和規則組成。然而，Scrum 規則 不像角色、事件和工件那樣可辨別。此列表試圖提煉此類 規則， 並作為 Scrum 指南™ 的補充資源提供。
雖然只實現 Scrum 的一部分是可能的，但結果不是 Scrum。 Scrum 僅存在於整體中，它作為其他技術、方法和實踐的容器運行良好。（第 19 頁）。Scrum 中的團隊模型旨在優化靈活性、創造力和生產力（第 6 頁）。在 Scrum 中使用規定的事件來創建規律性並最小化 Scrum 中未定義的會議的需求（第 9 頁）。工件代表工作或價值，以提供關鍵信息的透明度——以便每個人都對工件有相同的理解——以及檢查和適應的機會。（第 14 頁）
2. 流程的重要方面必須透明
Scrum 依賴於透明度（第 17 頁），這意味著流程的重要方面必須對負責結果的人可見。透明度要求這些方面由一個共同的標準來定義，以便觀察者對所看到的有一個共同的理解。例如，涉及過程的通用語言必須由所有參與者共享，執行工作的人和接受工作的人必須對“完成”有共同的定義。(pp. 5) Scrum Master 必須與產品負責人、開發團隊和其他相關方合作，以了解工件是否完全透明。Scrum Master 的工作是與 Scrum 團隊和組織合作，以增加工件的透明度。（第 17 頁）
3. Scrum 團隊必須經常檢查 Scrum 工件和進展
Scrum 用戶必須經常檢查 Scrum 工件並朝著 Sprint 目標前進，以檢測不合需要的差異。除了 Sprint 本身（它是所有其他事件的容器）之外，Scrum 中的每個事件都是檢查和調整某些內容的正式機會。（第 5、9 頁）
4. Scrum 團隊必須調整流程和工件以解決偏差
如果檢查員確定某個過程的一個或多個方面超出了可接受的範圍，並且所產生的產品將是不可接受的，則必須調整過程或正在處理的材料。必須盡快進行調整，以盡量減少進一步的偏差。（第 5 頁）
5. Sprint 被限制在一個月或更短的時間內
Scrum 的核心是一個 Sprint，一個一個月或更短的時間盒，在此期間創建“完成”、可用且可能發布的產品增量。 Sprint 僅限於一個日曆月，因為 當 Sprint 的範圍太長時，正在構建的定義可能會發生變化，複雜性可能會增加，風險可能會增加。衝刺通過確保至少每個日曆月檢查和調整目標進度來實現可預測性。Sprint 還將風險限制在一個日曆月的成本內。（第 9 頁）
6. Sprint 具有一致的持續時間
在整個開發工作中，Sprint具有一致的持續時間。新的 Sprint 在上一個 Sprint 結束後立即開始。（第 9 頁）
7. Sprint 是連續的
Sprint 包含並由 Sprint 計劃、Daily Scrums、開發工作、Sprint Review 和 Sprint Retrospective 組成。新的 Sprint 在上一個 Sprint 結束後立即開始。（第 9 頁）
8. 所有的 Scrum 事件都是有時間限制的
所有的事件都是有時間限制的，這樣每個事件都有一個最長的持續時間。除了 Sprint 本身，它是所有其他事件的容器，只要達到事件的目的，事件就可以結束。Scrum Master 教導 Scrum 團隊將每個事件保持在其相應的時間範圍內（第 10-14 頁）。
- Sprint 計劃（在 Sprint 期間每週最多兩個小時）
- 每日站會（15 分鐘）
- Sprint Review（在 Sprint 期間每週最多一小時）
- Sprint 回顧（在 Sprint 期間每週最多 45 分鐘）
9. Scrum Master 負責促進和支持定義的 Scrum
Scrum Master 負責促進和支持 Scrum 指南中定義的 Scrum。 Scrum Master 通過幫助每個人理解 Scrum 理論、實踐、規則和價值觀來做到這一點。Scrum Master 幫助 Scrum 團隊之外的人了解他們與 Scrum 團隊的哪些互動有幫助，哪些沒有。Scrum Master 幫助每個人改變這些交互，以最大化 Scrum 團隊創造的價值（第 7 頁）。 Scrum Master 確保所有事件都發生並且服務員了解他們的目的 （第 9-14 頁）。
10. Scrum Master 是 Scrum 團隊的僕人式領導者
Scrum Masters 首先是僕人，他們主要關注 Scrum 團隊的成長和福祉及其互動。Scrum Master 為 Scrum 團隊服務，根據要求或需要提供指導、輔導和促進活動。Scrum Master 還消除了開發團隊進展的障礙。Scrum Master 幫助 Scrum 團隊之外的人了解他們與 Scrum 團隊的哪些互動有幫助，哪些沒有。Scrum Master 幫助每個人改變這些交互，以最大化 Scrum 團隊創造的價值。（第 7 頁）
11. 產品待辦列表是需求的單一來源
產品待辦列表是產品中已知需要的所有內容的有序列表，並且是對產品進行任何更改的唯一需求來源（第 15 頁）。沒有人可以強迫開發團隊根據一組不同的要求工作（第 6 頁）。產品待辦列表項具有描述、訂單、估計和價值等屬性。產品待辦列表項通常包括測試描述，以在“完成”時證明其完整性。（第 15 頁）
12. 一個產品；一個產品待辦列表
即使多個 Scrum 團隊在同一產品上工作，也只使用一個 Product Backlog。然後可以使用對項目進行分組的產品待辦列表屬性。（第 15 頁）
13. 產品待辦列表永遠不會完整
產品待辦列表永遠不會完整。它的最早開發僅列出了最初已知和最容易理解的要求。如果產品存在，則其產品待辦列表也存在。（第 15 頁）
14. 產品負責人是唯一負責管理產品待辦列表的人
產品負責人負責產品待辦列表，包括其內容、可用性和訂購（第 15 頁）。儘管開發團隊可能會執行積壓管理活動，但產品負責人仍然負責。（第 6 頁）
15. 產品負責人是一個人，而不是一個委員會
產品負責人可以在產品待辦列表中代表委員會的願望，但那些想要改變產品待辦列表項的優先級的人必須向產品負責人提出意見。（第 5 頁）
16. 產品負責人負責最大化價值
產品負責人負責最大化產品的價值和開發團隊的工作。為了讓產品負責人取得成功，整個組織都必須尊重他或她的決定。產品負責人的決定在產品待辦列表的內容和順序中可見。（第 6 頁）
17. 開發團隊負責創建增量
開發團隊由專業人士組成，他們負責在每個 Sprint 結束時交付潛在可發布的“完成”產品增量。只有開發團隊的成員才能創建增量。（第 7 頁）
18. 開發團隊是自組織的
開發團隊由組織構建並授權以組織和管理他們自己的工作。沒有人（甚至不是 Scrum Master）告訴開發團隊如何將產品待辦列表轉化為潛在可發布功能的增量。（第 7 頁）
19. 開發團隊是跨職能的
作為一個團隊，開發團隊擁有創建產品增量所需的所有技能。（第 7 頁）
20. 開發組3-9人
開發團隊的規模小到足以保持敏捷，大到足以完成 Sprint 中的重要工作。少於三名成員的開發團隊可能會在 Sprint 期間遇到技能限制，並且可能無法交付潛在的可發布增量。超過九名成員需要太多的協調，並為經驗過程帶來太多的複雜性。（第 7 頁）
21. 開發團隊的所有成員共享同一個頭銜
除了開發人員之外，Scrum 不承認開發團隊成員的任何頭銜。（第 7 頁）
22. 開發團隊沒有子團隊
Scrum 不承認開發團隊中的任何子團隊，無論需要解決哪些領域，如測試或業務分析。（第 7 頁）
23. 整個開發團隊負責
個別團隊成員可能具有專業技能和重點領域，但責任屬於開發團隊。（第 7 頁）
24. Scrum 團隊必須對“完成”有一個共同的理解
當產品待辦列表項或增量被描述為“完成”時，每個人都必須理解“完成”的含義。“完成”的這個定義確保了透明度，它用於評估產品增量的工作何時完成。相同的定義指導開發團隊了解在 Sprint 計劃期間可以選擇多少產品待辦列表項。如果“完成”的定義是開發組織的約定、標准或指南的一部分，則所有 Scrum 團隊必須至少遵守它。如果多個 Scrum 團隊正在處理系統或產品發布，則所有 Scrum 團隊的開發團隊必須相互定義“完成”的定義（第 18 頁）
25. 針對即將到來的 Sprint 的 Product Backlog 項目已經足夠細化
將在即將到來的 Sprint 中佔據開發團隊的產品待辦列表項被細化，以便任何一項都可以在 Sprint 時間框內合理地“完成”。Scrum 團隊決定改進的方式和時間。（第 15 頁）
26. 開發團隊負責所有估算
開發團隊負責所有 [規模、工作量] 估計。產品負責人可以通過幫助開發團隊理解和選擇權衡來影響開發團隊，但誰將執行工作做出最終估計。隨著工作的執行或完成，估計的剩餘工作會更新（第 15-16 頁）
27. 開發團隊決定需要做多少工作
從 Sprint 的產品待辦列表中選擇的項目數量完全取決於開發團隊。只有開發團隊可以評估它在即將到來的 Sprint 中可以完成的工作。（第 9 頁）。開發團隊應該能夠向產品負責人和 Scrum Master 解釋它打算如何作為一個自組織團隊來完成 Sprint 目標並創建預期的增量。（第 10 頁）
28. Sprint Backlog 就是 Sprint 計劃
Sprint Backlog 是為 Sprint 選擇的產品 Backlog 項目的集合，加上交付產品增量和實現 Sprint 目標的計劃。Sprint Backlog 使開發團隊確定為實現 Sprint 目標所必需的所有工作可見，並且它具有足夠的細節，可以在 Daily Scrum 中了解正在進行的更改。（第 16 頁）
29. Sprint Backlog 包含改進項目
為確保持續改進，Sprint Backlog 至少包括在上次回顧會議中確定的一項高優先級流程改進。（第 16 頁）
30. 開發團隊全權負責 Sprint Backlog
Sprint Backlog 是開發團隊計劃在 Sprint 期間完成的工作的高度可見的實時圖片，它完全屬於開發團隊。只有開發團隊可以在 Sprint 期間更改其 Sprint Backlog。（第 16 頁）
31. Sprint Backlog 出現
開發團隊在整個 Sprint 中修改 Sprint Backlog, Sprint Backlog 在 Sprint 期間出現。當需要新工作時，開發團隊將其添加到 Sprint 待辦列表中。（第 16 頁）
32. 開發團隊監控衝刺目標的進展
開發團隊至少為每個 Daily Scrum 跟踪 Sprint 中剩餘的總工作量，以預測實現 Sprint 目標的可能性。Sprint Backlog 有足夠的細節，可以在 Daily Scrum 中了解正在進行的更改。隨著工作的執行或完成，估計的剩餘工作會更新。當計劃的元素被認為是不必要的時，它們將被刪除。（第 16 頁）
33. Sprint 開始後，其持續時間是固定的
與其他 Scrum 事件不同的是， 只要達到事件的目的就可能結束，一旦 Sprint 開始，其持續時間是固定的，不能縮短或延長。（第 9 頁）
34. Sprint 受到保護
在 Sprint 期間，不會進行任何會危及 Sprint 目標的更改，並且質量目標不會降低。隨著了解的更多，產品負責人和開發團隊之間可能會澄清和重新協商範圍。（第 9 頁）
35. 只有產品負責人有權取消 Sprint
可以在 Sprint 時間框結束之前取消 Sprint，但只有產品負責人有權這樣做。任何已完成和“已完成”的產品待辦列表項都會被審查，產品負責人接受任何可能可發布的工作部分。（第 10 頁）
36. 每日站會在同一時間和地點舉行
每日站會在同一時間和地點舉行以降低複雜性。（第 12 頁）
37. 開發團隊負責進行 Daily Scrum
Scrum Master 確保開發團隊召開會議，但開發團隊負責主持每日 Scrum。（第 12 頁）
38. 只有開發團隊參與 Daily Scrum
Scrum Master 確保只有開發團隊成員參與（即回答三個問題）每日 Scrum。（第 12 頁）
39.增量是累積的
增量是 Sprint 期間完成的所有產品待辦列表項的總和以及所有先前 Sprint 的增量值。（第 17 頁）
40. Increment 必須處於可用狀態
在 Sprint 評審中需要“完成”增量。每個 Sprint 的目的是交付符合 Scrum 團隊當前“完成”定義的潛在可發布功能的增量。在 Sprint 結束時，新的增量必須處於可用狀態，無論產品負責人是否決定發布它。（第 17 頁）
41. Sprint 評審檢查增量並產生修訂後的產品待辦列表
Sprint 評審會在 Sprint 結束時進行，以檢查增量並在需要時調整產品待辦列表。Sprint Review 是非正式會議，而不是狀態會議。增量的介紹旨在引起反饋並促進合作。Sprint 評審的結果是一個修訂的產品待辦列表，它定義了下一個 Sprint 可能的產品待辦列表項。（第 13 頁）
42. 產品負責人監控實現長期目標的進展
在任何時間點，都可以匯總達到目標所需的總工作量。產品負責人至少在每個 Sprint 評審中跟踪剩餘的總工作量。（第 16 頁）
43. Sprint 回顧應該導致改進
Sprint 回顧是 Scrum 團隊自我檢查並製定改進計劃的機會，以便在下一個 Sprint 期間實施。Scrum Master 鼓勵 Scrum 團隊改進其開發過程和實踐，使其在下一個 Sprint 中更加有效和愉快。在 Sprint 回顧結束時，Scrum 團隊應該已經確定將在下一個 Sprint 中實施的改進。（第 14 頁）