2020《Scrum 指南》™

ScrumGuides.guru: 全中文繁體版 PDF ，全中文简体版

Scrum 指南的目的

我們在 1990 年代初期開發出 Scrum。為了協助全世界的人們了解 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 採行迭代 (iterative) 和增量的 (incremental) 方法來優化對未來的預測性並控制風險。Scrum 讓一群共同擁有全部所需之技能與專長的人員從事工作，並視需要分享及獲得這些技能。

Scrum 有四個正式檢視與調適的事件，並且用另外一個事件：Sprint 來包含這四個事件。這些事件起作用的原因是它們實現了以經驗為導向的 Scrum 支柱：透明性、檢視性與調適性。

透明性 (Transparency)

湧現的 (emergent) 流程和工作必須對執行工作和接收工作的人員都是可見的。在 Scrum 裡，重要的決策是基於對其三個正式工件的感知狀態。透明性低的工件會導致做出讓價值減少且風險增加的決策。

透明性促成檢視性。 没有透明性的檢視會產生誤導和浪費。

檢視性 (Inspection)

必須要經常用心地檢視 Scrum 的工件與一致同意的目標進度，以便發現潛在的誤差和問題。為了有助於檢視性，Scrum 以五個事件的形式提供了穩定的節奏。

檢視性促成調適性。 沒有調適性的檢視是沒有意義的。Scrum 的事件旨在激發改變。

調適性 (Adaptation)

若是流程的任何方面已偏離且超出可接受的範圍，或是所得的產品無法被接受，則必須將所採用的流程或其打造出來的材料進行調整。調整工作必須盡快執行，以減少未來更多的偏差。

當相關人員未獲得賦權 (empowered)，或無法自我管理時 (self-managing)，調適性將變得更加艱難。一個 Scrum 團隊透過檢視而學習到的新事物之當下，應當立刻調適。

Scrum 的價值觀

Scrum 的成功應用取決於人們更完善地活出這五項價值觀：

「承諾、專注、開放、尊重、與勇氣」

Scrum 團隊致力於達成其目標並彼此相互支援。他們主要專注在 Sprint 的工作，盡可能地朝向目標前進，以獲取最好的進展。Scrum 團隊與其利害關係人對於工作及挑戰抱持著開放的態度。Scrum 團隊的成員們互相尊重對方是個有能力和獨立的人，同時也受其他同事同等的尊重。Scrum 團隊的成員們有勇氣去做對的事情、並處理棘手的問題。

這些價值觀指引了 Scrum 團隊的工作、行動與行為。所做出的決定、所採取的步驟與如何使用 Scrum 都應該反覆的加強這些價值觀，而不是削弱或破壞這些價值觀。Scrum 團隊成員們依照 Scrum 的事件和工件來學習並探索這些價值觀。當 Scrum 團隊以及與工作的同事們展現了這些價值觀，就能活現出 Scrum 經驗的支柱：透明性、檢視性與調適性，並在每個人之間建立信任。

Scrum 團隊 (Scrum Team)

Scrum 以小團隊作為基本單位，稱為 Scrum 團隊。 Scrum 團隊由一名 Scrum Master、一名產品負責人與開發人員所組成。在 Scrum 團隊內沒有子團隊或是階級架構，是由一群具有凝聚力的專業人士，一次只專注在一個目標上：產品目的。

Scrum 團隊是跨職能 (cross-functional) 的，也就是說，成員們擁有在 Sprint 內創造價值所需的所有技能。他們也是自我管理的，也就是說，他們在團隊內部決定誰做什麼、何時做以及如何做。

Scrum 團隊規模足夠小以保持靈活性，同時足夠大以便可以在 Sprint 內完成有意義的工作，通常人數在 10 人以下。一般而言，我們發現越小的團隊溝通越好，生產力更高。如果 Scrum 團隊變得太大，他們應該考慮重新組織為多個有凝聚力的 Scrum 團隊，每個團隊還是專注在同一個產品，因此，他們應該有著相同的產品目的、產品待辦清單和產品負責人。

Scrum 團隊負責所有與產品相關的活動，像是與利害關係人的協同合作、驗證、維護、營運、實驗、研究、和開發以及任何其他可能需要的工作。組織成立 Scrum 團隊並賦權他們自行管理工作。在 Sprint 中維持可持續的步調工作，可以加強 Scrum 團隊的專注與一致性。

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

開發人員 (Developers)

Scrum 團隊當中的開發人員是指在每個 Sprint 致力於打造任何可用增量的成員。

開發人員所須具備的特定技能通常很廣泛，並且會隨著工作領域不同而有别。然而，開發人員總是對以下事項負有責任：

  • 打造一份 Sprint 的計畫，也就是 Sprint 待辦清單；
  • 藉由遵循完成之定義，以灌輸品質；
  • 每天調適其邁向 Sprint 目的之計畫；和，
  • 作為專業人士對彼此負責。

產品負責人 (Product Owner)

產品負責人負責將把 Scrum 團隊的工作所打造出來的產品價值最大化。如何做到這一點可能會依組織、Scrum 團隊和個人的不同而有極大的差異。

產品負責人也負責對產品待辦清單進行有效的管理，包括：

  • 發展並明確的描述溝通產品目的；
  • 創造並清楚的描述溝通產品待辦清單項目 (Product Backlog items)；
  • 對產品待辦清單項目進行排序；和，
  • 確保產品待辦清單是透明的、可見的與可理解的。

產品負責人可以自己做上述工作，或者也可以將職責委託他人，然而，產品負責人仍肩負最終責任。

為了讓產品負責人成功，整個組織必須尊重他們的決定，這些決定在產品待辦清單内容和順序中可以被看見，並且在 Sprint 評審事件時透過可檢視的增量展現出來。

產品負責人是一個人，而不是一個委員會。在產品待辦清單中，產品負責人可能代表了許多利害關係人的需求，想要改變產品待辦清單的人可以試著去說服產品負責人。

Scrum Master

Scrum Master 負責按照 Scrum 指南來建立 Scrum，方式是透過幫助 Scrum 團隊內與組織內部的每個人了解 Scrum 的理論與實作。

Scrum Master 對 Scrum 團隊的效能負責。 他們透過讓 Scrum 團隊在 Scrum 框架內改善其實務作法來做到這一點。

Scrum Masters 是真正的領導者，服務對象是 Scrum 團隊和更大範圍的組織。

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

  • 以教練方式提升團隊成員的自我管理與跨職能能力；
  • 協助 Scrum 團隊專注於打造出滿足完成之定義且具備高價值的增量；
  • 促使 Scrum 團隊的阻礙被移除掉；
  • 確保所有的 Scrum 事件都舉行，有建設性、有成效的並且保持在時間盒內 (timebox) 進行。

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

  • 幫助找到有效定義產品目的與管理產品待辦清單的技巧；
  • 幫助 Scrum 團隊理解為何需要清楚且簡明的產品待辦清單項目；
  • 幫助在錯綜複雜的環境下，建立以經驗為導向的產品計畫 (empirical product planning)；和，
  • 當被要求或需要時，引導利害關係人的協同運作。

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

  • 在組織採用 Scrum 的過程中，以領導、訓練和教練方式帶領組織；
  • 在組織內，規劃並指導 Scrum 的執行運作；
  • 幫助員工和利害關係人理解與制定以經驗為導向的方法 (empirical approach) 來處理錯綜複雜的工作；
  • 移除利害關係人與 Scrum 團隊之間的障礙。

Scrum 事件 (Scrum Events)

Sprint 是所有其他事件的容器。 Scrum 中的每個事件都是用來檢視與調適 Scrum 工件的正式機會。這些事件都是為實現所需要的透明性而特別設計的。未能按規定運作任何事件將導致失去檢視和調適的機會。 Scrum 使用事件來創造規律性，並以此減少 Scrum 中未定義的會議的需要。

最理想的是，所有事件都在同一時間同一地點舉行，以減少複雜性。

Sprint

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

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

所有為了達成產品目的之工作都發生在各個 Sprints 內，包括 Sprint 計劃事件、每日 Scrum 事件、Sprint 評審事件、和 Sprint 回顧事件。

在 Sprint 期間：

  • 不得做出危及 Sprint 目的之改變；
  • 不得降低品質；
  • 需要時將產品待辦清單精煉; 和；
  • 隨著學到更多，可以與產品負責人針對範疇作進一步澄清與重新協商。

藉由至少每個月一次對邁向產品目的之進度來進行檢視與調適，Sprint 促成了可預測性。當Sprint 的時間太長，可能導致 Sprint 目的失效，複雜性的程度可能會上升，以及風險可能會增高。採用時間較短的 Sprint，可以建立更多學習周期，並將成本與氣力的風險控制在一個較短的時間内。每一個 Sprint 都可以視為一個短期專案。

用來預測進度的實務做法有很多種，像是燃盡圖 (burn-downs)、燃起圖 (burn-ups)，或是累積流量圖 (cumulative flows)。雖然這些做法是有用處的，但不能取代經驗主義的重要性。在錯綜複雜的環境中，接下來會發生什麼是不可知的。只有已經發生的事物才能用來做前瞻性的決策基礎。

若 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，這個事件所需時間通常會更短。

每日 Scrum 事件 (Daily Scrum)

每日 Scrum 事件的用途是檢視目前 Sprint 目的之進度，並根據需要調適 Sprint 待辦清單，以調整即將到來的計畫工作。

每日 Scrum 事件是一個屬於Scrum 團隊當中的開發人員的 15 分鐘事件。為了降低複雜性，它在 Sprint 內的每個工作天會在同樣時間、同樣地點舉行。如果產品負責人或 Scrum Master 正在積極地處理 Sprint 待辦清單上的工作項目，他們會以開發人員的身份參與。

開發人員可以選擇他們想要的任何每日 Scrum 事件的結構和技術，只要他們的每日 Scrum 事件專注於實現 Sprint 目的之進展，並且產生下一個工作天可執行的計畫。這樣可以更專注並改進自我管理。

每日 Scrum 事件增加溝通、點出障礙、促進快速決策，從而消除其他會議的需要。

每日 Scrum 事件並不是開發人員唯一一次允許調整計劃的時間，在一整天的工作中，他們常常會見面詳細討論要如何做出調適，或是重新計畫 Sprint 剩下的工作。

Sprint 評審事件 (Sprint Review)

Sprint 評審事件的用途是檢視此 Sprint 的成果和決定未來的調適方向。Scrum 團隊向利害關係人展示他們的工作結果，並討論產品目的之進展情況。

在這個事件中，Scrum 團隊與利害關係人回顧在 Sprint 中完成的成果，以及環境發生了什麼變化，基於這些資訊，與會者對接下來要做什麼進行協同合作，也可調整產品待辦清單，藉此來掌握新的機會。Sprint 評審事件是一個工作會議，Scrum 團隊應避免將其限於投影片展示。

Sprint 評審事件是每個 Sprint 最後倒數的第二個事件，是有時間盒限定的：一個月的 Sprint 最多為四個小時；而較短的 Sprint，這個事件所需時間通常會更短。

Sprint 回顧事件 (Sprint Retrospective)

Sprint 回顧事件的用途是規劃出能提升品質與效能的方法。

Scrum 團隊檢視上個 Sprint 中有關人員、互動、流程、工具以及他們的完成之定義的情況。被檢視的元素通常隨工作領域而不同。團隊會辨識出他們迷失方向的假設，並探究這些假設的起源。Scrum 團隊討論此次 Sprint 中，什麼進展順利，遇到哪些問題，以及如何（或為何無法）解決這些問題。

Scrum 團隊辨識出最有用的改變以提升其效能。最具衝擊力的改善行動將儘速執行。甚至可以納入到下一個 Sprint 的 Sprint 待辦清單中。

Sprint 回顧事件是總結 Sprint 的事件。是有時間盒限定的，以一個月的 Sprint 來說，最多為 3 個小時；而較短的 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 指南的歷史

Ken Schwaber 和 Jeff Sutherland在 1995 年 OOPSLA 的大會上首次聯合發表 Scrum。這場演講本質上記錄了 Ken 和 Jeff 在過去幾年的學習成果，也首次公開了 Scrum 的正式定義。

Scrum 指南記錄了 Jeff Sutherland 和 Ken Schwaber 在三十多年間對 Scrum 的開發，演進，和維護。其他的資​​源在模式、流程和見解方面為 Scrum 框架提供了補充。這些可能可以提高生產力、價值、創造力和對結果的滿意度。

Scrum 的完整歷史在其他地方有所記載。我們對於首先嘗試並證實其有效的公司表達敬意：Individual, Inc., Newspage, Fidelity Investments, 和 IDX（現為 GE Medical）。

致謝繁體中文譯者

本繁體中文指南 2020 版由上述致謝的開發者 Ken Schwaber 和 Jeff Sutherland 所提供的英文原版 2020 版翻譯而來。

全中文版譯者：

同時，我們對以往中文版的譯者表示感謝：

  • 2020 中文翻譯組：周建成、王晶、李奇霖、葛仲安、林偉弘、蘇於登和王泰瑞。
  • 2017 简体：周建成；繁體：張裕宇、王泰瑞、林偉弘。
  • 2016 简体：周建成。
  • 2013 简体：李麟德、王军；繁體：林偉弘。
  • 2011 简体：鲍央舟、孙媛。

2020 年 Scrum 指南版本更新說明

1. 甚至更少的規範指示

這些年來， Scrum 指南開始變得有一些規範指示。 2020 年版本旨在透過刪除或淡化規定性用語，使 Scrum 恢復到原本最低限度的框架。 例如刪除了每日 Scrum 事件的三個提問，淡化了關於產品待辦清單項目屬性的用語，淡化了關於 Sprint 待辦清單中改進項目的相關描述，減化了取消 Sprint 的段落，等等其它更多部分。

2. 一個團隊，專注於一個產品

目的在消除團隊中有其它團隊的概念，導致產品負責人和開發團隊之間出現「代理人」或「我們跟他們」的行為。現在只有一個 Scrum 團隊專注於同一目標，有三個不同當責： 產品負責人，SM 和開發人員。

3. 加入產品目的

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

4. Sprint 目的、完成之定義和產品目的有了歸宿

先前版本的 Scrum 指南描述了 Sprint 目的和完成之定義，但是沒有真正賦予它們明確的身份。 它們不全然是工件，反而是類似依附在工件。 隨著增加了產品目的，2020 版本對此提供了更清晰的說明。 現在，三個工件中都包含一個相對應的「承諾」。 對於產品待辦清單，它相對應的是產品目的，Sprint 待辦清單則有 Sprint 目的，而增量有完成之定義（現在，完成不再加引號）。 這些承諾的存在是為了帶來透明性，並專注於每個工件的進度。

5. 自我管理超越自我組織

先前版本的 Scrum 指南將 Development Team 稱為自我組織的，他們能選擇人員和如何做事。 2020 版本更加著重於 Scrum 團隊，強調了一個自我管理的 Scrum 團隊，他們能選擇人員，如何做事，和做什麼事。

6. 三個 Sprint 計劃事件的主題

Sprint 計劃事件主題除了「什麼」和「如何」之外，2020年 Scrum 指南還強調了第三個主題 「為什麼」，這裏的「為什麼」指的是 Sprint 目的。

7. 擴大讀者範圍，全面簡化用語

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 指南，您認可以及同意以創作共用的署名相同方式共享的條約。

此版本的 Scrum 指南是根據 2020 年 11 月版本的英文版 Scrum Guide 翻譯的。 如果對這個版本有任何的問題或建議，歡迎寫信給 feedback@ScrumGuides.guru 或在 GitHub 上提出來討論 (連結)