（Scrum Guides由 Ken Schwaber 和 Jeff Sutherland 最初于1995年發布并演講，英文原版鏈接 www.scrumguides.org。轉載請注明來自：http://www.boskyuan.cn/scrum-guide-chinese/，此2020版本由優普豐根據官方版本修訂)

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. 一名產品負責人將解決復雜問題所需的工作整理成一份產品待辦列表。
2. Scrum 團隊在 一個 Sprint 期間將選擇的工作轉化為價值的增量。
3. Scrum 團隊和利益攸關者檢視結果并為下一個 Sprint 進行調整。
4. 重復

Scrum 是易于理解的。原封不動地去嘗試，并確定其哲學、理論和結構是否有助于實現目標和創造價值。 Scrum 框架故意不完整，僅定義了實施 Scrum 理論所需的部分。Scrum 建立在其使用者的集體智慧之上。Scrum 的規則沒有為人們提供詳細的使用說明，而是指導他們之間的關系和互動。

在 Scrum 框架中，可以使用各種不同的過程、技術和方法。Scrum可以將一些已有的實踐包裝進來，也可以甄別出非必須的實踐。Scrum 可以凸顯當前管理、環境和工作技術的相對成效，以便可以進行改進。

Scrum 理論

Scrum 基于經驗主義和精益思維。 經驗主義主張知識源自實際經驗以及根據當前觀察到的事物作出的判斷所獲得。精益思維減少浪費，專注于根本。

Scrum 采納一種迭代和增量的方法來優化對未來的預測性并控制風險。 Scrum 讓一群共同擁有所有技能和專長的人員參與進來完成工作，并根據需要分享或獲得所需技能。

Scrum 將四個正式事件組合在一起以在一個容器型事件 Sprint 中進行檢視和適應。這5個事件之所以起作用，是因為它們實現了基于經驗主義的 Scrum 的三個支柱：透明、檢視和適應。

透明（Transparency）

涌現的過程和工作成果必須對執行工作的人員和接受工作的人員都是可見的和一致理解的。在 Scrum 中，重要的決策是基于其 3 個正式工件的感知狀態。透明度較低的工件可能導致做出降低價值并增加風險的決策。

透明使檢視成為可能。沒有透明和共識的檢視會產生誤導和浪費。

檢視（Inspection）

Scrum 工件和實現商定目標的進展必須經常地和勤勉地檢視，以便發現潛在的不良的差異或問題。為了幫助檢視，Scrum 以 5 個事件的形式提供了穩定的節奏。

檢視使適應成為可能。沒有適應的檢視是毫無意義的。Scrum 事件旨在激發改變。

調整（Adaptation）

如果過程的任何方面超出可接受的范圍或所得的產品不可接受，就必須對當下的過程或過程處理的內容加以調整。 調整工作必須盡快執行以最小化進一步的偏差。

當所涉人員沒有得到授權或不能自管理時，則適應將變得更加困難。 在通過檢視學到任何新東西時，Scrum 團隊會做出相應調整。

Scrum 價值觀

Scrum 的成功應用取決于人們變得更加精通踐行并內化 5 項價值觀：

承諾， 專注， 開放， 尊重，勇氣

Scrum 團隊致力于達成其目標并且相互支持。他們主要專注于 Sprint 的工作，以便盡可能地向著這些目標獲取最好的進展。 Scrum 團隊及其利益攸關者對工作和挑戰持開放態度。 Scrum 團隊成員相互尊重，彼此是有能力和獨立的人，并因此受到與他們一起工作的人的尊重。Scrum 團隊成員有勇氣做正確的事并處理那些棘手的問題。

這些價值觀為 Scrum 團隊的工作、行動和行為指引方向。做出的決定、采取的步驟以及使用Scrum 的方式應強化這些價值觀，而不是削弱或破壞它們。Scrum 團隊成員通過 Scrum 事件和工件來學習和探索這些價值觀。當 Scrum 團隊和與他們一起工作的人們體現這些價值觀時，基于經驗主義的 Scrum 的三個支柱：透明、檢視和適應，就成為現實，并在每個人之間構建信任。

Scrum 團隊（Scrum Team）

Scrum 的基本單位是小團隊，稱為 Scrum Team。 Scrum 團隊由一名 Scrum Master，一名產品負責人和開發人員組成。在 Scrum 團隊中，沒有子團隊或層次結構。Scrum 團隊是具有凝聚力的專業團體，一次專注于一個目標，即產品目標。

Scrum 團隊是跨職能的，這意味著團隊成員具有在每個 Sprint 中創造價值而所需的全部技能。他們也是自管理的，這意味著他們在團隊內部決定誰做什么、何時做以及如何做。

Scrum 團隊規模足夠小以保持靈活，同時足夠大以便可以在一個 Sprint 中完成有意義的工作，通常只有 10 人或更少。總的來說，我們發現較小的團隊溝通更好，效率更高。如果 Scrum 團隊變得太大，則應考慮將他們重組為多個具有凝聚力的 Scrum 團隊，每個團隊都專注于同一產品。因此，他們應該共享相同的產品目標、產品待辦列表和產品負責人。

Scrum 團隊負責所有與產品相關的活動，包括與利益攸關者的協作、驗證、維護、運營、實驗、研究和開發，以及可能需要進行的其他任何活動。組織組建并授權 Scrum 團隊自行管理他們自己的工作。以可持續的速度在 Sprint 中工作可以提高 Scrum 團隊的專注度和一致性。

整個 Scrum 團隊都有責任在每個 Sprint 中創建有價值的、有用的增量。 Scrum 在 Scrum 團隊中定義了三種特定的職責擔當（Accountability）：開發人員、產品負責人和 Scrum Master。

開發人員（Developers）

開發人員是 Scrum 團隊中致力于創建每個 Sprint 可用增量的任何方面的人員。

開發人員所需的特定技能通常很廣泛，并且會隨著工作領域的不同而變化。但是， 開發人員始終要負責：

• 為Sprint創建計劃，即 Sprint 待辦列表；
• 通過遵循完成的定義來注入質量；
• 每天根據 Sprint 目標調整計劃； 和，
• 作為專業人士對彼此負責。

產品負責人（Product Owner）

產品負責人負責將 Scrum 團隊的工作所產生的產品價值最大化。 如何做到這一點可能在組織、Scrum 團隊和個體之間存在很大差異。

產品負責人還負責對產品待辦列表進行有效管理，包括：

• 開發并明確地溝通產品目標；
• 創建并清晰地溝通產品待辦列表項；
• 對產品待辦列表項進行排序； 和，
• 確保產品待辦列表是透明的、可見的和可理解的。

產品負責人可以自己做上述工作，或者也可以將職責委托他人。 然而無論如何， 產品負責人是擔當最終責任的人。

為保證產品負責人取得成功，整個組織必須尊重他們的決定。這些決定在產品待辦列表的內容和順序中可見，并在 Sprint 評審會議時透過可檢視的增量予以體現。

產品負責人是一個人，而不是一個委員會。在產品待辦列表中，產品負責人可以代表許多利益攸關者的期望要求。那些想要改變產品待辦列表的人可以嘗試去說服產品負責人來做到這一點。

Scrum Master （敏捷教練和領導者）

Scrum Master 負責按照 Scrum 指南的游戲規則來建立 Scrum。他們通過幫助 Scrum 團隊和組織內的每個人理解 Scrum 理論和實踐來做到這一點。

Scrum Master 對 Scrum 團隊的效能負責。他們通過讓 Scrum 團隊在 Scrum 框架內改進其實踐來做到這一點。

Scrum Masters 是真正的領導者，服務于 Scrum 團隊和作為更大范圍的組織。

Scrum Master 以多種方式服務于 Scrum 團隊，包括：

• 作為教練在自管理和跨職能方面輔導 Scrum 團隊成員；
• 幫助 Scrum 團隊專注于創建符合完成的定義的高價值增量；
• 促使移除 Scrum 團隊工作進展中的障礙；和，
• 確保所有 Scrum 事件都發生并且是積極的、富有成效的，并且在時間盒內完成。

Scrum Master 以多種方式服務于產品負責人，包括：

• 幫助找到有效定義產品目標和管理產品待辦列表的技巧；
• 幫助 Scrum 團隊理解為何需要清晰且簡明的產品待辦列表項；
• 幫助建立針對復雜環境的基于經驗主義的產品規劃；和，
• 當需要或被要求時，引導利益攸關者協作。

Scrum Master 以多種方式服務于組織，包括：

• 帶領、培訓和作為教練輔導組織采納 Scrum；
• 在組織范圍內規劃并建議 Scrum 的實施；
• 幫助員工和利益攸關者理解并實施針對復雜工作的經驗主義方法；和，
• 消除利益攸關者和 Scrum 團隊之間的隔閡。

Scrum 事件

Sprint 是所有其他事件的容器。Scrum 中的每個事件都是檢視和適應 Scrum 工件的正式機會。這些事件都是為實現所需的透明度而特別設計的。未能按規定運作任何事件將導致失去檢視和適應的機會。Scrum 使用事件來創造規律性，并以此最小化對 Scrum 中未定義的會議的需要。 最理想的是，所有事件都在同一時間同一地點舉行，以便減少復雜性。

Sprint （短迭代時間盒）

Sprint 是 Scrum 的核心，在這里創意轉化為價值。

它們是固定時長的事件，為期一個月或更短，以保持一致性。前一個 Sprint 結束后，下一個新的 Sprint 緊接著立即開始。

實現產品目標所需的所有工作，包括 Sprint 計劃會議、每日 Scrum 會議、Sprint 評審會議和 Sprint 回顧會議，都發生在 Sprint 內。

在 Sprint 期間：

• 不能做出危及 Sprint 目標的改變；
• 不能降低質量；
• 產品待辦列表按需進行精化，和
• 隨著學到更多，可以與產品負責人就范圍加以澄清和重新協商。

Sprint 通過確保至少每個自然月一次對達成產品目標的進展進行檢視和適應，來實現可預測性。當 Sprint 的時間長度拉得太長時，Sprint 目標可能會失效，復雜性可能會上升，同時風險可能會增加。可以使用較短的 Sprint 來產生更多的學習周期，并將成本與工作投入的風險限制在更短的一段時間內。每個 Sprint 都可以視為一個短期的項目。

存在各種各樣的實踐來預測進展，例如，燃盡圖、燃起圖或累積流圖。盡管被證明是有用的，然而這些實踐并不能用來取代經驗主義的重要性。在復雜的環境中，未來將要發生什么是未知的。只有已經發生的事情才能用來做前瞻性的決策。

如果 Sprint 目標已過時，那么就可以取消 Sprint。只有產品負責人擁有取消 Sprint 的權力。

Sprint 計劃會議（Sprint Planning）

Sprint 計劃會議通過安排在 Sprint 中要做的工作來啟動 Sprint。最終的計劃是由整個 Scrum 團隊協作創建的。

產品負責人要確保與會者準備好討論最重要的產品待辦列表項 ，以及它們如何映射到產品目標。Scrum 團隊還可以邀請其他人參加 Sprint 計劃會議以提供建議。

Sprint 計劃會議處理以下話題：

話題一：為什么這次 Sprint 有價值？

產品負責人提議產品如何在當前的 Sprint 中增加其價值和效用。然后，整個 Scrum 團隊將共同制定一個 Sprint 目標，用以溝通當前 Sprint 對利益攸關者有價值的原因。必須在 Sprint 計劃會議結束之前最終確定 Sprint 目標。

話題二：這次 Sprint 能完成（Done）什么？

通過與產品負責人討論， 開發人員從產品待辦列表中選擇一些產品待辦列表項，放入當前 Sprint 中。 Scrum 團隊可以在此過程中精化這些產品待辦列表項，從而增加理解和信心。

選擇在 Sprint 中可以完成多少任務可能會有挑戰。 但是，開發人員對他們以往的表現，他們在即將到來的 Sprint 內的產能以及對他們的完成的定義了解得越多，他們對 Sprint 預測就越有信心。

話題三：如何完成所選的工作？

對于每個選定的產品待辦列表項，開發人員都會規劃必要的工作，以便創建符合完成的定義的增量。這通常是通過將產品待辦列表項分解為一天或更短的較小項來完成的。開發人員自行決定如何完成這一工作。沒有人告訴他們如何將產品待辦列表項轉化為價值的增量。

Sprint 目標、這次 Sprint 所選出的產品待辦列表項加上如何交付它們的計劃稱之為 Sprint 待辦列表。

Sprint 計劃會議是有時間盒限定的，以一個月的 Sprint 來說最多為 8 個小時。對于更短的 Sprint，Sprint 計劃會議所需時間通常會更短。

每日 Scrum 會議（Daily Scrum）

每日 Scrum 會議的目的是檢視達成 Sprint 目標的進展，并根據需要調整適應 Sprint 待辦列表，以調整即將進行的計劃工作。

每日 Scrum 會議是一個屬于 Scrum 團隊的開發人員的 15 分鐘的事件。為了降低復雜性，它在 Sprint 的每個工作日都在同一時間同一地點舉行。如果產品負責人或 Scrum Master 正在積極處理 Sprint 待辦列表上的項，那么他們將作為開發人員參與其中。

開發人員可以選擇他們想要的任何舉行每日 Scrum 會議的結構和技術，只要他們專注于實現 Sprint 目標的進展，并為下一工作日的工作制定可行的計劃即可。這可以創建專注點并改進自管理。

每日 Scrum 會議改善溝通，發現障礙，促進快速決策，從而消除其他會議的需要。

每日 Scrum 會議并不是唯一一次允許開發人員調整計劃的時間。他們可以在一天中任何時間碰面，詳細討論如何調整適應或重新規劃 Sprint 的剩余工作。

Sprint 評審會議（Sprint Review）

Sprint 評審會議的目的是檢視 Sprint 的成果并確定未來的適應性。Scrum 團隊向關鍵利益攸關者展示他們的工作結果，并討論產品目標的進展情況。

在 Sprint 評審會議期間，Scrum 團隊和利益攸關者將評審在這次 Sprint 中完成了什么，以及環境發生了什么變化。基于這些信息，與會者可以就下一步的工作進行協作。產品待辦列表也可能會進行調整以適應新的機會。Sprint 評審會議是一個工作會議，Scrum 團隊應避免將其僅限于展示。

Sprint 評審會議是 Sprint 的倒數第二個事件，Sprint 評審會議是有時間盒限定的，以一個月的 Sprint 來說，最多為 4 個小時。 對于更短的 Sprint，Sprint 評審會議通常所需的時間更短。

Sprint 回顧會議（Sprint Retrospective）

Sprint 回顧會議的目的是規劃提高質量和效能的方法。

Scrum 團隊檢視最近 Sprint 中有關個體、交互、過程、工具和他們的完成的定義的情況如何。被檢查的元素通常隨工作領域而變化。識別使他們誤入歧途的假設，并探究其起源。Scrum 團隊討論在 Sprint 期間哪些進展順利，遭遇到哪些問題以及這些問題是如何解決（或未解決）的。

Scrum 團隊識別出最有用的改變以提高其效能。最有影響力的改進將盡快得到執行。甚至可以將它們添加到下一個 Sprint 的 Sprint 待辦列表中。

Sprint 回顧會議結束 Sprint。它是有時間盒限定的，以一個月的 Sprint 來說，最多為 3 個小時。對于更短的 Sprint， Sprint 回顧會議通常所需的時間更短。

Scrum 工件（Scrum Artifacts)

Scrum 的工件代表工作或價值。 它們旨在最大限度地提高關鍵信息的透明度。 因此，為適應而檢視它們的每個人對工件都有相同的基礎。

每個工件都包含一個承諾，以確保它提供可增強透明度并聚焦于可度量進展的信息：

• 對于產品待辦列表而言，它是產品目標。
• 對于 Sprint 待辦列表而言，它是 Sprint 目標。
• 對于增量而言，它是完成的定義。

這些承諾的存在是為了強化經驗主義和 Scrum 團隊及其利益攸關者的 Scrum 價值觀。

產品待辦列表（Product Backlog）

產品待辦列表是一份涌現的和有序的清單，它列出了改進產品所需的內容。它是 Scrum 團隊所承擔工作的唯一來源。

能夠被 Scrum 團隊在一個 Sprint 中完成（Done）的產品待辦列表項被認為準備就緒，在 Sprint 計劃會議事件中可供選擇。它們通常在精化活動后獲得這種透明度。產品待辦列表精化是將產品待辦列表項分解并進一步定義為更小更精確的行為。這是一項持續進行的活動，為產品待辦列表項增添細節，例如描述、優先順序和規模。這些屬性通常隨工作領域而變化。

將要做這項工作的開發人員負責使其適當的大小。產品負責人可以通過幫助開發人員理解和權衡取舍來影響他們。

承諾：產品目標（Product Goal）

產品目標描述了產品的未來狀態，可以作為 Scrum 團隊制定計劃的目標。產品目標在產品待辦列表中。產品待辦列表的其余部分涌現，用來定義“做什么”將實現產品目標。

產品是傳遞價值的載體。它具有明確的邊界、已知的利益攸關者和定義明確的用戶或客戶。產品可以是一種服務、實體產品或其他更抽象的東西。

產品目標是 Scrum 團隊的長期目標。他們必須先實現（或放棄）一個目標，然后再開始下一個目標。

Sprint 待辦列表（Sprint Backlog ）

Sprint 待辦列表由 Sprint 目標（為什么做）、為 Sprint 選擇的產品待辦列表項（做什么）以及交付增量的可執行計劃（如何做）組成。

Sprint 待辦列表是開發人員為其制定的計劃。它是開發人員在 Sprint 期間為實現 Sprint 目標而計劃完成的工作，是一個高度可視且實時的工作畫面。因此，隨著學到更多，Sprint 待辦列表在整個 Sprint 期間會進行更新。它應該有足夠的細節，以便他們可以在每日 Scrum 會議中檢視其進展。

承諾： Sprint 目標（Sprint Goal）

Sprint 目標是 Sprint 的單個目標。盡管 Sprint 目標是開發人員的承諾，但它為實現該目標所需的確切工作方面提供了靈活性。 Sprint 目標還創造了連貫性和專注點，鼓勵 Scrum 團隊一起工作而不是分開獨自行動。

Sprint 目標在 Sprint 計劃會議事件中確定，然后添加到 Sprint 待辦列表中。當開發人員在 Sprint 期間工作時，他們將 Sprint 目標銘記在心。如果需要做的工作與預期的不同，他們將與產品負責人協作，在不影響 Sprint 目標的情況下，協商本次 Sprint 待辦列表的范圍。

增量（Increment）

一個增量是邁向產品目標的一塊堅實墊腳石。每個增量都是之前所有的增量累加起來的，并經過徹底地驗證，以確保整合在一起的所有增量都能工作。為了提供價值，增量必須是可用的。

在一個 Sprint 中可以創建多個增量。 增量的總和在 Sprint 評審會議中展示，從而支持經驗主義。 但是，增量可以在 Sprint 結束之前交付給利益攸關者。Sprint 評審會議決不應該被視為發布價值的關口。

一項工作除非符合完成的定義，否則不能將其視為增量的一部分。

承諾： 完成的定義（Definition of Done）

完成的定義是當增量符合產品所需的質量度量標準時對其狀態的正式描述。

當一個產品待辦列表項符合完成的定義時，就會產生一個增量。

完成的定義通過使每一個人對作為增量的一部分、什么樣的工作算是已完成的工作有一個共同的理解來創建透明。如果一個產品待辦列表項不符合完成的定義，那么它就不能發布，甚至不能在 Sprint 評審會議中展示它。相反，它返回到產品待辦列表中以供將來考慮。

如果增量的完成的定義是組織標準的一部分，那么所有 Scrum 團隊都必須以此為最低標準來遵守。如果它不是組織標準的一部分，那么 Scrum 團隊必須制定適合于該產品的完成的定義 。

開發人員需要遵守完成的定義。如果有多個 Scrum 團隊在同一產品上一起工作，那么他們必須一起制定并遵守同樣的完成的定義。

結束語

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 醫療）表示致敬。

附：從2017 版到 2020 版指南的變更

規定性更低

這些年來，Scrum 指南開始變得越來越有規定性。 2020 版旨在通過刪除或淡化規定性語言，使 Scrum 重新成為最低限度的框架。例如刪除了每日 Scrum 會議三個提問，淡化了關于產品待辦列表項屬性的相關描述，淡化了 Sprint 待辦列表中改進項的相關描述，刪除了“取消 Sprint”一節更改為更為簡單的描述 ，等等。

一個團隊，專注于一個產品

我們的目標是消除導致產品負責人和 Dev 團隊之間出現“代理”或“我們與他們”行為的團隊中獨立團隊的概念。現在只有一個 Scrum 團隊專注于同一目標，有三種不同的職責擔當：產品負責人、ScrumMaster 和開發人員。

產品目標介紹

2020 版 Scrum 指南引入了產品目標的概念，為 Scrum 團隊提供了一個更具價值的目標的專注點。每個 Sprint 都應使產品更接近整體的產品目標。

給 Sprint 目標、完成的定義和產品目標安了家

之前版本的 Scrum 指南描述了 Sprint 目標和完成的定義，但是沒有真正賦予它們一個身份。 它們不是完全意義上的工件，而是在某種程度上依附于工件。 隨著產品目標的增加，2020 版對此提供了更為清晰的說明。現在，三個工件中的每一個都包含一個相應的的“承諾”。 對于產品待辦列表，它是產品目標，對于 Sprint 待辦列表 則是 Sprint 目標，而增量則是完成的定義（現在，完成不再加引號）。它們的存在是為了帶來透明度，并專注于每個工件的進展。

自管理勝過自組織

之前版本的 Scrum 指南將開發團隊稱為自組織，選擇誰和如何做。 2020 版更關注 Scrum 團隊，強調一個自管理的 Scrum 團隊，選擇誰、如何做以及做什么。

三個 Sprint 計劃會議話題

Sprint 計劃會議的話題除了“什么”和“如何”之外， 2020 版 Scrum 指南還強調了第三個話題“為什么”，即 Sprint 目標。

為更廣泛的受眾而全面簡化語言

2020 版 Scrum 指南著重于消除冗余和復雜的陳述，以及刪除所有與 IT工作相關的推斷（例如，測試、系統、設計、需求，等等）。現在， Scrum 指南不到 13 頁。

? 2020 Ken Schwaber and Jeff Sutherland This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons. 使用本 Scrum 指南，您認可以及同意以知識共享許可協議的署名-相同方式共享的條款。

?

PDF下載鏈接

http://www.boskyuan.cn/wp-content/uploads/2020/11/2020-Scrum-Guide-Chinese-Simplified.pdf