本文轉自：Scrum中文網
原文鏈接：https://www.scrumcn.com/agile/scrum/24060.html
Scrum指南由Ken Schwaber & Jeff Sutherland和維護，這是剛剛發布的2020版Scrum指南的中文版。
Scrum指南的目的
在 1990 年代初，我們開發了Scrum。在 2010 年，我們撰寫首版Scrum 指南，以幫助全世界的人們理解 Scrum。自那時起，我們通過小的功能更新對 Scrum 指南進行了演進。我們是Scrum 指南的共同后盾。
Scrum 指南包含了Scrum 的定義。框架的每個元素都有其特定的目的，這對於使用Scrum 實現全部價值和成果是至關重要的。如果更改Scrum 的核心設計或理念、遺漏元素或不遵循Scrum 的規則，將掩蓋問題並限制Scrum 的好處，甚至可能變得毫無用途。
我們關注到Scrum 在日益復雜的世界中應用越來越廣泛。我們很榮幸地看到 Scrum 在許多本質上具有復雜性的工作領域中被采用，超越了 Scrum 的起源領域——軟件產品開發。隨着Scrum 的應用范圍不斷擴大，developers、研究人員、分析師、科學家和其他專家都能在工作中應用。因此， 我們在 Scrum 中使用 “developers” 一詞並不是為了排除其他使用者，而是為了簡化統稱。如果您從 Scrum 中獲得價值，那么您可以將自己視為其中一員。
在使用 Scrum 時，可能可以找到、應用和設計適合本文中所描述的 Scrum 框架的模式、過程和見解。它們的描述超出了Scrum 指南的目的，因為它們因 Scrum 的使用具體情境不同而不同。這些使用 Scrum 框架的特定技巧有很大的差異，因此不在本文中描述。
Scrum的定義
Scrum 是一個輕量的框架，它通過提供針對復雜問題的自適應解決方案來幫助人們、團隊和組織創造價值。
簡而言之，Scrum 需要 Scrum Master 營造一個環境，從而：
1. 一名 Product Owner 將解決復雜問題所需的工作整理成一份Product Backlog。
2. Scrum Team 在 一個 Sprint 期間將選擇的工作轉化為價值的 Increment。
3. Scrum Team 和利益攸關者檢視結果並為下一個Sprint 進行調整。
4. 重復
Scrum 是易於理解的。原封不動地去嘗試，並確定其哲學、理論和結構是否有助於實現目標和創造價值。Scrum 框架故意不完整，僅定義了實施Scrum 理論所需的部分。Scrum 建立在其使用者的集體智慧之上。Scrum 的規則沒有為人們提供詳細的使用說明，而是指導他們之間的關系和互動。
在 Scrum 框架中，可以使用各種不同的過程、技術和方法。Scrum 可以將一些已有的實踐包裝進來，也可以甄別出非必須的實踐。Scrum 可以凸顯當前管理、環境和工作技術的相對成效，以便可以進行改進。
Scrum 理論
Scrum 基於經驗主義和精益思維。經驗主義主張知識源自實際經驗以及根據當前觀察到的事物作出的判斷所獲得。精益思維減少浪費，專注於根本。
Scrum 采納一種迭代和增量的方法來優化對未來的預測性並控制風險。Scrum 讓一群共同擁有所有技能和專長的人員參與進來完成工作，並根據需要分享或獲得所需技能。
Scrum 將 4 個正式事件組合在一起以在一個容器型事件 Sprint 中進行檢視和適應。這些事件之所以起作用，是因為它們實現了基於經驗主義的Scrum 的三個支柱：透明、檢視和適應。
透明
涌現的過程和工作必須對執行工作的人員和接受工作的人員都是可見的。在 Scrum 中，重要的決策是基於其 3 個正式工件的感知狀態。透明度較低的工件可能導致做出降低價值並增加風險的決策。
透明使檢視成為可能。沒有透明的檢視會產生誤導和浪費。
檢視
Scrum 工件和實現商定目標的進展必須經常地和勤勉地檢視，以便發現潛在的不良的差異或問題。為了幫助檢視，Scrum 以 5 個事件的形式提供了穩定的節奏。
檢視使適應成為可能。沒有適應的檢視是毫無意義的。Scrum 事件旨在激發改變。
適應
如果過程的任何方面超出可接受的范圍或所得的產品不可接受，就必須對當下的過程或過程處理的內容加以調整。調整工作必須盡快執行以最小化進一步的偏差。
當所涉人員沒有得到授權或不能自管理（self-managing）時，則適應將變得更加困難。在通過檢視學到任何新東西時，Scrum Team 會做出相應調整。
Scrum 價值觀
Scrum 的成功應用取決於人們變得更加精通踐行並內化 5 項價值觀
承諾， 專注， 開放， 尊重和勇氣
Scrum Team 致力於達成其目標並且相互支持。他們的主要關注點是 Sprint 的工作，以便盡可能地向着這些目標獲取最好的進展。Scrum Team 及其利益攸關者對工作和挑戰持開放態度。Scrum Team 成員相互尊重，彼此是有能力和獨立的人，並因此受到與他們一起工作的人的尊重。Scrum Team 成員有勇氣做正確的事並處理那些棘手的問題
這些價值觀為Scrum Team 的工作、行動和行為指引方向。做出的決定、采取的步驟以及使用Scrum 的方式應強化這些價值觀，而不是削弱或破壞它們。Scrum Team 成員通過Scrum 事件和工件來學習和探索這些價值觀。當 Scrum Team 和與他們一起工作的人們體現這些價值觀時，基於經驗主義的 Scrum 的三個支柱：透明、檢視和適應，就成為現實，並在每個人之間構建信任。Scrum 價值觀
Scrum Team
Scrum 的基本單位是小團隊，稱為Scrum Team。Scrum Team 由一名Scrum Master，一名 Product Owner 和 Developers 組成。在 Scrum Team 中，沒有子團隊或層次結構。Scrum Team 是具有凝聚力的專業團體，一次專注於一個目標，即 Product Goal。
Scrum Team 是跨職能的（cross-functional），這意味着團隊成員具有在每個 Sprint 中創造價值而所需的全部技能。他們也是自管理的，這意味着他們在團隊內部決定誰做什么、何時做以及如何做。
Scrum Team 規模足夠小以保持靈活，同時足夠大以便可以在 一個 Sprint 中完成重要的工作，通常只有 10 人或更少。總的來說，我們發現較小的團隊溝通更好，效率更高。如果 Scrum Team 變得太大，則應考慮將他們重組為多個具有凝聚力的Scrum Team，每個團隊都專注於同一產品。因此，他們應該共享相同的Product Goal、Product Backlog 和 Product Owner。
Scrum Team 負責所有與產品相關的活動，包括與利益攸關者的協作、驗證、維護、運營、實驗、研究和開發，以及可能需要進行的其他任何活動。組織組建並授權Scrum Team 自行管理他們自己的工作。以可持續的速度在Sprint 中工作可以提高Scrum Team 的專注度和一致性。
整個Scrum Team 都有責任在每個Sprint 中創建有價值的、有用的Increment。Scrum 在 Scrum Team 中定義了三種特定的職責：Developers、Product Owner 和 Scrum Master。
Developers
Developers 是 Scrum Team 中致力於創建每個Sprint 可用 Increment 的任何方面的人員。
Developers 所需的特定技能通常很廣泛，並且會隨着工作領域的不同而變化。但是， Developers始終要負責：
● 為 Sprint 創建計划，即Sprint Backlog；
● 通過遵循 Definition of Done 來注入質量；
● 每天根據 Sprint Goal 調整計划；
● 作為專業人士對彼此負責。
Product Owner
Product Owner 負責將Scrum Team 的工作所產生的產品價值最大化。如何做到這一點可能在組織、Scrum Team 和個體之間存在很大差異。
Product Owner 還負責對Product Backlog 進行有效管理，包括：
● 開發並明確地溝通Product Goal ；
● 創建並清晰地溝通Product Backlog 條目（items）；
● 對 Product Backlog 條目進行排序；
● 確保 Product Backlog 是透明的、可見的和可理解的。
Product Owner 可以自己做上述工作，或者也可以將職責委托他人。然而無論如何， Product Owner 是負最終責任的人。
為保證 Product Owner 取得成功，整個組織必須尊重他們的決定。這些決定在Product Backlog 的內容和順序中可見，並在 Sprint Review 時透過可檢視的 Increment 予以體現。
Product Owner 是一個人，而不是一個委員會。在Product Backlog 中，Product Owner 可以代表許多利益攸關者的期望要求。那些想要改變 Product Backlog 的人可以嘗試去說服Product Owner 來做到這一點。
Scrum Master
Scrum Master 負責按照Scrum 指南的游戲規則來建立Scrum。他們通過幫助Scrum Team 和組織內的每個人理解 Scrum 理論和實踐來做到這一點。
Scrum Master 對 Scrum Team 的效能負責。他們通過讓Scrum Team 在 Scrum 框架內改進其實踐來做到這一點
Scrum Masters 是真正的領導者，服務於Scrum Team 和作為更大范圍的組織。
Scrum Master 以多種方式服務於Scrum Team ，包括：
● 作為教練在自管理和跨職能方面輔導Scrum Team 成員；
● 幫助 Scrum Team 專注於創建符合 Definition of Done 的高價值 Increment；
● 促使移除 Scrum Team 工作進展中的障礙；
● 確保所有 Scrum 事件都發生並且是積極的、富有成效的，並且在時間盒（timebox）內完成。
Scrum Master 以多種方式服務於Product Owner，包括：
● 幫助找到有效定義Product Goal 和管理Product Backlog 的技巧；
● 幫助 Scrum Team 理解為何需要清晰且簡明的Product Backlog 條目；
●幫助建立針對復雜環境的基於經驗主義的產品規划（empirical product planning）；
● 當需要或被要求時，引導利益攸關者協作。
Scrum Master 以多種方式服務於組織，包括：
● 帶領、培訓和作為教練輔導組織采納Scrum；
● 在組織范圍內規划並建議Scrum 的實施；
● 幫助員工和利益攸關者理解並實施針對復雜工作的經驗主義方法（empirical approach）；
● 消除利益攸關者和Scrum Teams 之間的隔閡。
Scrum事件
Sprint 是所有其他事件的容器。Scrum 中的每個事件都是檢視和適應Scrum 工件的正式機會。這些事件都是為實現所需的透明度而特別設計的。未能按規定運作任何事件將導致失去檢視和適應的機會。Scrum 使用事件來創造規律性，並以此最小化對Scrum 中未定義的會議的需要。
最理想的是，所有事件都在同一時間同一地點舉行，以便減少復雜性。
Sprint
Sprint 是 Scrum 的核心，在這里創意（idea）轉化為價值。
它們是固定時長的事件，為期一個月或更短，以保持一致性。前一個Sprint 結束后，下一個新的Sprint 緊接着立即開始。
實現 Product Goal 所需的所有工作，包括Sprint Planning、Daily Scrum、Sprint Review 和 Sprint Retrospective，都發生在 Sprint 內。
在 Sprint 期間：
● 不能做出危及Sprint Goal 的改變；
● 不能降低質量；
● Product Backlog 按需進行精化（refined），和
● 隨着學到更多，可以與Product Owner 就范圍加以澄清和重新協商。
Sprint 通過確保至少每個日歷月一次對達成Product Goal 的進展進行檢視和適應，來實現可預測性。當 Sprint 的長度拉得太長時，Sprint Goal 可能會失效，復雜性可能會上升，同時風險可能會增加。可以使用較短的Sprint 來產生更多的學習周期，並將成本與工作投入（effort）的風險限制在更短的一段時間內。每個Sprint 都可以視為一個短期的項目。
存在各種各樣的實踐來預測進展，例如，燃盡圖（burn-downs）、燃起圖（burn-ups）或累積流圖（cumulative flows）。盡管被證明是有用的，然而這些實踐並不能用來取代經驗主義的重要性。在復雜的環境中，未來將要發生什么是未知的。只有已經發生的事情才能用來做前瞻性的決策。
如果 Sprint Goal 已過時，那么就可以取消Sprint。只有 Product Owner 有取消Sprint 的權力。
Sprint Planning
Sprint Planning 通過安排在 Sprint 中要做的工作來啟動 Sprint。最終的計划是由整個 Scrum Team 協作創建的。
Product Owner 要確保與會者准備好討論最重要的Product Backlog 條目 ，以及它們如何映射到Product Goal 。Scrum Team 還可以邀請其他人參加Sprint Planning 以提供建議。
Sprint Planning 處理以下話題：
話題一：為什么這次 Sprint 有價值？
Product Owner 提議產品如何在當前的Sprint 中增加其價值和效用。然后，整個 Scrum Team 將共同制定一個 Sprint Goal ，用以溝通當前Sprint 對利益攸關者有價值的原因。必須在Sprint Planning 結束之前最終確定 Sprint Goal 。
話題二：這次 Sprint 能完成（Done）什么？
通過與 Product Owner 討論， Developers 從 Product Backlog 中選擇一些條目，放入當前Sprint中。Scrum Team 可以在此過程中精化這些Product Backlog 條目，從而增加理解和信心。
選擇在 Sprint 中可以完成多少任務可能會有挑戰。但是，Developers 對他們以往的表現，他們在即將到來的Sprint 內的產能以及對他們的Definition of Done 了解得越多，他們對 Sprint 預測就越有信心。
話題三：如何完成所選的工作？
對於每個選定的Product Backlog 條目，Developers 都會規划必要的工作，以便創建符合Definition of Done 的 Increment。這通常是通過將Product Backlog 條目分解為一天或更短的較小條目來完成的。Developers 自行決定如何完成這一工作。沒有人告訴他們如何將Product Backlog 條目轉化為價值的 Increment。
Sprint Goal 、這次 Sprint 所選出的Product Backlog 條目加上如何交付它們的計划稱之為Sprint Backlog。
Sprint Planning 是有時間盒限定的，以一個月的Sprint 來說最多為 8 個小時。對於更短的 Sprint， Sprint Planning 所需時間通常會更短。
Daily Scrum
Daily Scrum 的目的是檢視達成 Sprint Goal 的進展，並根據需要調整適應Sprint Backlog，以調整即將進行的計划工作。
Daily Scrum 是一個屬於Scrum Team 的 Developers 的 15 分鍾的事件。為了降低復雜性，它在Sprint 的每個工作日都在同一時間同一地點舉行。如果 Product Owner 或 Scrum Master 正在積極處理 Sprint Backlog 條目，那么他們將作為Developers 參與其中。
Developers 可以選擇他們想要的任何舉行Daily Scrum 的結構和技術，只要他們專注於實現Sprint Goal 的進展，並為下一工作日的工作制定可行的計划即可。這可以創建專注點並改進自管理。
Daily Scrum 改善溝通，發現障礙，促進快速決策，從而消除其他會議的需要。
Daily Scrum 並不是唯一一次允許Developers 調整計划的時間。他們可以在一天中任何時間碰面， 詳細討論如何調整適應或重新規划Sprint 的剩余工作。
Sprint Review
Sprint Review 的目的是檢視 Sprint 的成果並確定未來的適應性。Scrum Team 向關鍵利益攸關者展示他們的工作結果，並討論Product Goal 的進展情況。
在 Sprint Review 期間，Scrum Team 和利益攸關者將評審在這次Sprint 中完成了什么，以及環境發生了什么變化。基於這些信息，與會者可以就下一步的工作進行協作。Product Backlog 也可能會進行調整以適應新的機會。Sprint Review 是一個工作會議，Scrum Team 應避免將其僅限於展示。
Sprint Review 是 Sprint 的倒數第二個事件，Sprint Review 是有時間盒限定的，以一個月的 Sprint 來說，最多為 4 個小時。對於更短的Sprint，Sprint Review 通常所需的時間更短。
Sprint Retrospective
Sprint Retrospective 的目的是規划提高質量和效能的方法。
Scrum Team 檢視最近 Sprint 中有關個體、交互、過程、工具和他們的 Definition of Done 的情況如何。被檢查的元素通常隨工作領域而變化。識別使他們誤入歧途的假設，並探究其起源。Scrum Team 討論在 Sprint 期間哪些進展順利，遭遇到哪些問題以及這些問題是如何解決（或未解決） 的。
Scrum Team 識別出最有用的改變以提高其效能。最有影響力的改進將盡快得到執行。甚至可以將它們添加到下一個 Sprint 的 Sprint Backlog 中。
Sprint Retrospective 結束 Sprint。它是有時間盒限定的，以一個月的 Sprint 來說，最多為 3 個小時。對於更短的 Sprint， Sprint Retrospective 通常所需的時間更短。
Scrum工件
Scrum 的工件代表工作或價值。它們旨在最大限度地提高關鍵信息的透明度。因此，為適應而檢視它們的每個人對工件都有相同的基礎。
每個工件都包含一個承諾，以確保它提供可增強透明度並聚焦於可度量進展的信息：
● 對於 Product Backlog 而言，它是 Product Goal。
● 對於 Sprint Backlog 而言，它是 Sprint Goal 。
● 對於 Increment 而言，它是Definition of Done。
這些承諾的存在是為了強化經驗主義和Scrum Team 及其利益攸關者的Scrum 價值觀。
Product Backlog
Product Backlog 是一份涌現的和有序的清單，它列出了改進產品所需的內容。它是Scrum Team 所承擔工作的唯一來源。
能夠被 Scrum Team 在一個Sprint 中完成（Done）的 Product Backlog 條目被認為准備就緒，在Sprint Planning 事件中可供選擇。它們通常在精化活動后獲得這種透明度。Product Backlog 精化是將 Product Backlog 條目分解並進一步定義為更小更精確的行為。這是一項持續進行的活動，為Product Backlog 條目增添細節，例如描述、優先順序和規模。這些屬性通常隨工作領域而變化。
將要做這項工作的Developers 負責使其適當的大小。Product Owner 可以通過幫助Developers 理解和權衡取舍來影響他們。
承諾：Product Goal
Product Goal 描述了產品的未來狀態，可以作為Scrum Team 制定計划的目標。Product Goal 在Product Backlog 中。Product Backlog 的其余部分涌現，用來定義“做什么”將實現 Product Goal。
產品是傳遞價值的載體。它具有明確的邊界、已知的利益攸關者和定義明確的用戶或客戶。產品可以是一種服務、實體產品或其他更抽象的東西。
Product Goal 是 Scrum Team 的長期目標。他們必須先實現（或放棄）一個目標，然后再開始下一個目標。
Sprint Backlog
Sprint Backlog 由 Sprint Goal （為什么做）、為 Sprint 選擇的 Product Backlog 條目（做什么）以及交付 Increment 的可執行計划（如何做）組成。
Sprint Backlog 是 Developers 為其制定的計划。它是 Developers 在 Sprint 期間為實現 Sprint Goal 而計划完成的工作，是一個高度可視且實時的工作畫面。因此，隨着學到更多，Sprint Backlog 在整個 Sprint 期間會進行更新。它應該有足夠的細節，以便他們可以在Daily Scrum 中檢視其進展。
承諾：Sprint Goal
Sprint Goal 是 Sprint 的單個目標。盡管 Sprint Goal 是 Developers 的承諾，但它為實現該目標所需的確切工作方面提供了靈活性。Sprint Goal 還創造了連貫性和專注點，鼓勵 Scrum Team 一起工作而不是分開獨自行動。
Sprint Goal 在 Sprint Planning 事件中確定，然后添加到 Sprint Backlog 中。當Developers 在 Sprint 期間工作時，他們將 Sprint Goal 銘記在心。如果需要做的工作與預期的不同，他們將與Product Owner 協作，在不影響 Sprint Goal 的情況下，協商本次Sprint Backlog 的范圍。
Increment
一個 Increment 是邁向 Product Goal 的一塊堅實墊腳石。每個 Increment 都是之前所有的Increment 累加起來的，並經過徹底地驗證，以確保整合在一起的所有Increment 都能工作。為了提供價值，Increment 必須是可用的。
在一個 Sprint 中可以創建多個Increment。Increment 的總和在 Sprint Review 中展示，從而支持經驗主義。但是，Increment 可以在 Sprint 結束之前交付給利益攸關者。Sprint Review 決不應該被視為發布價值的關口
一項工作除非符合Definition of Done ，否則不能將其視為 Increment 的一部分。
承諾：Definition of Done
Definition of Done 是當 Increment 符合產品所需的質量度量標准時對其狀態的正式描述。當一個 Product Backlog 條目符合 Definition of Done 時，就會產生一個 Increment。
Definition of Done 通過使每一個人對作為Increment 的一部分、什么樣的工作算是已完成的工作有一個共同的理解來創建透明。如果一個Product Backlog 條目不符合Definition of Done ，那么它就不能發布，甚至不能在 Sprint Review 中展示它。相反，它返回到Product Backlog 中以供將來考慮。
如果 Increment 的 Definition of Done 是組織標准的一部分，那么所有 Scrum Team 都必須以此為最低標准來遵守。如果它不是組織標准的一部分，那么 Scrum Team 必須制定適合於該產品的Definition of Done 。
Developers 需要遵守 Definition of Done。如果有多個Scrum Team 在同一產品上一起工作，那么他們必須一起制定並遵守同樣的 Definition of Done 。
結束語
Scrum 是免費的，並在本指南中提供。本文概述的Scrum 框架是不可改變的。雖然僅實施部分的Scrum 是可能的，但其結果就不是Scrum 了。Scrum 僅以完整形式而存在，唯其如此才能有效成為其他技術、方法和實踐的容器。
致謝：
人們
在為 Scrum 作出貢獻的成千上萬的人中，我們要特別指出那些在其最初提供幫助的人們：Jeff Sutherland 以及與他一道工作的Jeff McKenna 和 John Scumniotales，還有 Ken Schwaber 以及與他一道工作的Mike Smith 和 Chris Martin，他們一起工作 。在隨后的幾年中，許多其他人作出了貢獻，如果沒有他們的幫助，Scrum 不會被提煉至如今這般。
Scrum 指南歷史
在 1995 年的 OOPSLA 大會上，Ken Schwaber 和 Jeff Sutherland 首次聯合公開演講Scrum。這場演講本質是 Ken 和 Jeff 在之前數年運用Scrum 積累所得的記錄，並首次公開提出Scrum 的正式定義。
Scrum 指南記錄了Jeff Sutherland 和 Ken Schwaber 在 30 多年間對Scrum 的開發、演進和維護。此外，其他一些資源在模式、過程和見解方面為Scrum 框架提供了補充。這些可能可以提高生產力、價值、創造力和對結果的滿意度。
Scrum 的完整歷史在其他地方也有記載。我們向首先嘗試和證實Scrum 的公司：Individual Inc.， Newspage，Fidelity Investments 和 IDX（現為 GE 醫療）表示致敬。
致謝簡體中文譯者
本簡體中文指南( 2020 版 )由上述致謝的開發者Ken Schwaber 和 Jeff Sutherland 所提供的英文原版(2020 版)翻譯而來。中文指南（2020 版）由中文翻譯組翻譯。
中文翻譯組（scrum-guide-chinese-translators@googlegroups.com ）包括：周建成、王晶、李奇霖、葛仲安、林偉弘、蘇於登和王泰瑞。
同時，我們對以往中文版的譯者表示感謝：
2017：
簡體：周建成
繁體：張裕宇（Finn YuYu Chang）王泰瑞（Terry Wang）林偉弘（Andrew Lin）
2016：
簡體：周建成
2013：
簡體：李麟德（Derek Li）王軍（Jim Wang）
繁體：林偉弘（Andrew Lin）
2011：
簡體：鮑央舟 孫媛
從 2017 版到 2020 版指南的變更
規定性更低
這些年來，Scrum 指南開始變得越來越有規定性。2020 版旨在通過刪除或淡化規定性語言，使Scrum 重新成為最低限度的框架。例如刪除了 Daily Scrum 三個提問，淡化了關於PBI 屬性的相關描述，淡化了Sprint Backlog 中改進項的相關描述，刪除了“取消 Sprint”一節更改為更為簡單的描述 ，等等。
一個團隊，專注於一個產品
我們的目標是消除導致PO 和 Dev 團隊（Dev Team）之間出現“代理”或“我們與他們”行為的團隊中獨立團隊的概念。現在只有一個Scrum Team 專注於同一目標，有三種不同的職責：PO、SM 和Developers
Product Goal 介紹
2020 版 Scrum 指南引入了Product Goal 的概念，為Scrum Team 提供了一個更具價值的目標的專注點。每個 Sprint 都應使產品更接近整體的Product Goal。
給 Sprint Goal 、 Definition of Done 和 Product Goal 安了家
之前版本的Scrum 指南描述了 Sprint Goal 和 Definition of Done ，但是沒有真正賦予它們一個身份。它們不是完全意義上的工件，而是在某種程度上依附於工件。隨着Product Goal 的增加， 2020 版對此提供了更為清晰的說明。現在，三個工件中的每一個都包含一個相應的的“承諾”。對於 Product Backlog，它是Product Goal ，對於 Sprint Backlog 則是 Sprint Goal ，而 Increment 則是Definition of Done （現在，Done 不再加引號）。它們的存在是為了帶來透明度，並專注於每個工件的進展。
自管理勝過自組織
之前版本的Scrum 指南將開發團隊（ Development Team） 稱為自組織，選擇誰和如何做。2020
版更關注 Scrum Team，強調一個自管理的 Scrum Team，選擇誰、如何做以及做什么。
三個 Sprint Planning 話題
Sprint Planning 的話題除了“什么”和“如何”之外， 2020 版 Scrum 指南還強調了第三個話題“為什么”，即 Sprint Goal 。
為更廣泛的受眾而全面簡化語言
2020 版 Scrum 指南着重於消除冗余和復雜的陳述，以及刪除所有與 IT 工作相關的推斷（例如，測試、系統、設計、需求，等等）。現在， Scrum 指南不到 13 頁。