SCRUM敏捷开发官方权威指南
?
由Scrum創始人 Ken Schwaber 和 Jeff Sutherland 開發并維護
版本：2017中文版
SCRUM指南的目的
Scrum 是用于開發、交付和持續支持復雜產品的一個框架。本 Scrum指南 包含了 Scrum 的定義，其中包括 Scrum 的角色、事件、工件，以及把它們組織在一起的規則。Ken Schwaber 和 Jeff Sutherland 創造了 Scrum，Scrum 指南也由他們撰寫并提供。總之，他們是 Scrum 指南的后盾。
SCRUM的定義
Scrum（名詞）： Scrum 是一個框架，在此框架中人們可以解決復雜的自適應難題，同時也能高效并創造性地交付最高價值的產品。
Scrum 是：
- 輕量級的
- 易于理解的
- 難以精通的
Scrum 是一個框架，自上世紀 90 年代初以來，它就已經被應用于管理復雜產品的工作上。Scrum 并不是一種過程、技術或決定性方法。倒不如說，它是一個框架，在此框架中您可以使用各種不同的過程和技術。Scrum 讓您的產品管理和工作技術的相對成效更加清晰地顯現出來，以便您可以持續改進產品、團隊和工作環境。
Scrum 框架由Scrum 團隊以及與之相關的角色、事件、工件和規則組成。框架中的每個部分都有其特定的目的，其對于 Scrum 的成功與使用是至關重要的。
Scrum 的規則把角色、事件和工件組織在一起，管理它們之間的關系和交互。對于 Scrum 的規則描述將會貫穿全文。
使用 Scrum 框架的其它不同特定技巧將不在本文中描述。
SCRUM 的應用
Scrum 最初是為了管理和開發產品而開發的。從上世紀 90 年代初開始，Scrum 在全球范圍內已得到了廣泛應用：
1. 研究與確定可行的市場、技術和產品能力；
2. 開發產品和增強功能；
3. 每天頻繁多次發布產品和增強功能；
4. 為產品使用開發與支持云（在線、安全、按需）和其他運行環境；
5. 支持和更新產品。
Scrum 已被用于開發軟件、硬件、嵌入式軟件、交互功能網絡、自動駕駛、學校、政府、市場、管理組織運營，以及幾乎我們（作為個體和群體）日常生活中所使用的一切。
隨著技術、市場和環境的復雜性及其它們之間相互作用的快速增長，Scrum 在處理復雜性方面的效用日益得到證實。
在迭代與增量的知識遷移中，Scrum 被證明特別有效。Scrum 現廣泛用于產品、服務和母公司管理。
Scrum 的精髓在于小團隊。個體團隊具有高度靈活性和適應性。當單個、幾個、多個和團隊網絡在開發、發布、運營和維護成千上萬人的工作和工作產品時，這些優勢得以持續運作（并發揮價值）。他們通過精良的開發架構和目標發布環境來協作和互操作。
當 Scrum 指南使用“開發（動詞）”和“開發（名詞）”這兩個詞時，它們指的是復雜的工作，正如上述所確定的這些類型。
SCRUM 理論
Scrum 基于經驗過程控制理論，或稱之為經驗主義。經驗主義主張知識源自實際經驗以及當前已知情況下做出的決定所獲得。Scrum 采納一種迭代、增量式的方法來優化對未來的預測和控制風險。
透明、檢視和適應是經驗過程控制的三大支柱，支撐起每一個經驗過程的實施。
透明
過程中的關鍵環節對于那些對產出負責的人必須是顯而易見的。要擁有透明，就要為這些關鍵環節制定統一的標準，這樣所有留意這些環節的人都會對觀察到的事物有統一的理解。
例如
? 所有參與者談及過程時都必須使用統一的術語。
? 負責完成工作和檢視結果增量的人必須對“完成”的定義，有一致的理解。
檢視
Scrum 的使用者必須經常檢視 Scrum 的工件和完成 Sprint 目標的進展，以便發現不必要的差異。檢視不應該過于頻繁而阻礙工作本身。當檢視是由技能嫻熟的檢視者在工作中勤勉地執行時，效果最佳。
適應
如果檢視者發現過程中的一個或多個方面偏離可接受范圍以外，并且將會導致產品不可接受時，就必須對過程或過程化的內容加以調整。調整工作必須盡快執行如此才能最小化進一步的偏離。
Scrum 規定了 4 個正式事件，用于檢視與適應上，這 4 個事件在 Scrum 事件章節中會加以描述：
- Sprint 計劃會議
- ?每日 Scrum 站會
- Sprint 評審會議
- Sprint 回顧會議
SCRUM 價值觀
當承諾、勇氣、專注、開放和尊重五大價值觀為 Scrum 團隊所踐行與內化時，Scrum 的透明、檢視和適應三大支柱成為現實，并且在每個人之間構建信任。Scrum 團隊成員通過 Scrum 的角色、事件和工件來學習和探索這些價值觀。 Scrum 的成功應用取決于人們變得更為精通踐行五項價值觀。人們致力于實現 Scrum 團隊的目標。Scrum 團隊成員有勇氣去做正確的事并處理那些棘手的問題。每個人專注于 Sprint 工作和 Scrum 團隊的目標。Scrum 團隊及其干系人同意將所有工作和執行工作上的挑戰進行公開。Scrum 團隊成員相互尊重，彼此是有能力和獨立的人。
SCRUM 團隊
Scrum 團隊由一名產品負責人、開發團隊和一名 Scrum Master 組成。Scrum 團隊是跨職能的自組織團隊。自組織團隊自己選擇如何以最好的方式完成工作，而不是由團隊之外的人來指導。跨職能團隊擁有完成工作所需的全部技能，不需要依賴團隊之外的人。Scrum 團隊模式仍是設計用來提供最佳的靈活性、創造力和生產力。Scrum 團隊（自身）已經證明，對于所有之前所述 Scrum 的應用以及任何復雜工作來說，它都是越來越有效的。
Scrum 團隊迭代增量式地交付產品，籍此最大化地獲得反饋的機會。增量式交付“完成”的產品保證了一個可工作產品的潛在可用版本總是存在。
產品負責人
產品負責人的職責是將開發團隊開發的產品價值最大化。如何實現這一點的方式會隨著跨組織、Scrum 團隊和團隊成員個體的不同而有所不同。
產品負責人是負責管理產品待辦列表的唯一負責人。產品待辦列表的管理包括：
- 清晰地表述產品待辦列表項；
- 對產品待辦列表項進行排序，使其最好地實現目標和使命；
- 優化開發團隊所執行工作的價值；
- 確保產品待辦列表對所有人是可見、透明和清晰的，同時顯示 Scrum 團隊下一步要做的工作；以及
- ?確保開發團隊對產品待辦列表項有足夠深的了解。
產品負責人可以親自完成上述工作，或者也可以讓開發團隊來完成。然而無論何者，產品負責人是負最終責任的人。
產品負責人是一個人，而不是一個委員會。產品負責人可能會通過產品待辦列表展現一個委員會的期望要求，但是想要改變產品待辦列表項的優先級都必須經過產品負責人。
為保證產品負責人的工作取得成功，組織中的所有人員都必須尊重他/她的決定。產品負責人對產品待辦列表的內容和排序的決定必須是可見的。沒有人可以強迫開發團隊按照另一套需求開展工作。
開發團隊
開發團隊包含各種專業人員，負責在每個 Sprint 結束時交付潛在可發布并且“完成”的產品增量。在 Sprint 評審會議上，一個“完成”增量是必需的。只有開發團隊成員才能創建增量。
開發團隊由組織組建并得到授權，團隊自己組織和管理他們的工作。由此產生的正面效應能最大化開發團隊的整體效率和效用。
開發團隊具有下列特點：
- 他們是自組織的。沒有人（即使是 Scrum Master）有權告訴開發團隊應該如何把產品待辦列表變成潛在可發布的功能增量；
- 開發團隊是跨職能的團隊，團隊作為一個整體，擁有創建產品增量所需的全部技能；
- Scrum 不認可開發團隊成員的任何頭銜，不管其承擔何種工作（他們都叫開發人員）。
- Scrum 不認可開發團隊中所謂的“子團隊”，無論其需要處理的領域是諸如測試、架構、運維或業務分析；同時，
- 開發團隊中的每個成員也許有特長和專注的領域，但是責任屬于整個開發團隊。
開發團隊的規模
開發團隊最佳規模是足夠小以保持敏捷性，同時足夠大可以在 Sprint 內完成重要的工作。少于 3 個人的開發團隊，成員之間沒有足夠的互動，因而生產力的增長不會很大。過小的團隊在 Sprint 中可能會遭遇到技能上的約束，進而導致開發團隊無法交付潛在可發布的產品增量。超過 9 人的團隊則需要過多的協調溝通工作。對經驗過程而言，大型開發團隊會產生太多的復雜性而變得無用。產品負責人和 Scrum Master 角色不包含在此數字中，除非他們同時也參與執行 Sprint 待辦列表中的工作。
Scrum Master
Scrum Master 負責根據 Scrum 指南中的定義來促進和支持 Scrum。Scrum Master 通過幫助每個人理解 Scrum 理論、實踐、規則和價值來做到這一點。
Scrum Master 對 Scrum 團隊而言，他/她是一位服務型領導。Scrum Master 幫助 Scrum 團隊之外的人了解他/她如何與 Scrum 團隊交互是有益的，通過改變他/她們與 Scrum 團隊的互動方式來最大化 Scrum 團隊所創造的價值。
Scrum Master 服務于產品負責人
Scrum Master 以各種方式服務于產品負責人，包括：
- 盡可能確保 Scrum 團隊中的每個人都能理解目標、范圍和產品域；
- 找到有效管理產品待辦列表的技巧；
- 幫助 Scrum 團隊理解為何需要清晰且簡明的產品待辦列表項；
- 理解在經驗主義的環境中的產品規劃；
- 確保產品負責人懂得如何來安排產品待辦列表使其達到最大化價值；
- 理解并實踐敏捷性；以及，
- ?按要求或需要引導 Scrum 事件。
Scrum Master 服務于開發團隊
Scrum Master 以各種方式服務于開發團隊，包括：
- 在自組織和跨職能方面給予開發團隊指導
- ?幫助開發團隊創造高價值的產品；
- 移除開發團隊工作進展中的障礙；
- 按要求或需要引導 Scrum 事件；以及，
- 在 Scrum 還未完全采納和理解的組織環境中指導開發團隊。
Scrum Master 服務于組織
Scrum Master 以各種方式服務于組織，包括：
- ?帶領并指導組織采納 Scrum；
- 在組織范圍內規劃 Scrum 的實施；
- ?幫助員工和干系人理解并實施 Scrum 和經驗產品開發；
- 引發能夠提升 Scrum 團隊生產率的改變；以及，
- 與其他 Scrum Master 一起工作，增加組織中 Scrum 應用的有效性。
SCRUM 事件
Scrum 使用固定的事件來產生規律性，以此來減少 Scrum 之外的其他會議的必要。所有事件都是有時間盒限定的事件，也就是說每一個事件限制在最長的時間范圍內。一旦 Sprint 開始，它的持續時間是規定的，不能縮短或延長。而其他事件則可以在該事件的目標達成之后可以立即終止，如此確保時間被適當地使用而不會造成過程中的浪費。
Sprint 除了本身作為一個事件以外，它還是其他所有事件的容器，在 Scrum 中的每個事件都是用來進行檢視和適應的正式機會。這些事件都是被特別設計用來確保達成透明和檢視。如果 Sprint 不能成功地包含這些事件中的任何一個事件，導致透明化的降低，同時也會喪失進行檢視與適應的機會。
Sprint
Sprint 是 Scrum 的核心，其長度（持續時間）為一個月或更短的限時，這段時間內構建一個“完成”、可用的和潛在可發布的產品增量。在整個開發過程期間，Sprint 的長度保持一致。前一個 Sprint 結束后，新的下一個 Sprint 緊接著立即開始。
Sprint 由 Sprint 計劃會議、每日 Scrum 站會、開發工作、Sprint 評審會議和 Sprint 回顧會議構成。
在 Sprint 期間：
- 不能做出有害于 Sprint 目標的改變；
- 不能降低質量的目標；以及，
- 隨著對信息掌握的增加，產品負責人與開發團隊之間對范圍內要做的事可能會澄清和重新協商。
每個 Sprint 都可以被視為一個項目，為期不超過一個月。就如同項目一樣，Sprint 被用于完成某些事情。每個 Sprint 都會有一個要構建什么的目標，還有一份設計過和靈活的計劃用來指導如何做這些事、工作內容和最終產品增量。
Sprint 的長度限制在一個月內。當 Sprint 的長度太長的話，對要構建什么的定義就有可能會改變，復雜性也有可能會增加，同時風險也有可能會增加。Sprint 通過確保至少每月一次對達成目標的進度進行檢視和適應，來實現可預測性。Sprint 同時也把風險限制在一個月的成本上。
取消 Sprint
Sprint 可以在 Sprint 時間盒結束之前取消。只有產品負責人才有取消 Sprint 的權力，雖然他或她做這樣的決定也可能受到來自干系人、開發團隊或是 Scrum Master 的影響。
如果 Sprint 目標過時，那么 Sprint 就會被取消。比如公司的發展方向或者市場上或技術上的狀況發生改變，這些變化都可能導致 Sprint 被取消。總的來說，如果某個 Sprint 對其所在環境來說失去了價值和意義，那么它就應該被取消。然而，由于 Sprint 的時間都很短，所以取消 Sprint 的意義不大。
當取消某個 Sprint 時，任何做完和“完成”的產品待辦列表項都需要評審。假如成果的任何部分具有潛在可發布的話，產品負責人通常會接受這個成果。所有未完成的產品待辦列表項都會被放回到產品待辦列表中，并重新估算。花在它們身上的工作會很快地貶值，所以必須經常性地重估。
取消 Sprint 會消耗資源，因為每個人都重新集合在另外一個 Sprint 計劃會議來開始另一個 Sprint 。取消 Sprint 通常會對 Scrum 團隊造成重創，這種情況非常罕見。
Sprint 計劃會議
Sprint 中要做的工作在 Sprint 計劃會議中來做計劃。這份工作計劃是由整個 Scrum 團隊共同協作完成的。
Sprint 計劃會議是限時的，以一個月的 Sprint 來說最多 8 小時為上限。對于較短的 Sprint，會議時間通常會縮短。Scrum Master 要確保會議順利舉行，并且每個參會者都理解會議的目的。Scrum Master 要教導 Scrum 團隊遵守時間盒的規則。
Sprint 計劃會議回答以下問題：
- 接下來的 Sprint 交付的增量中要包含什么內容？
- 要如何完成交付增量所需的工作？
話題一：這次 Sprint 能做什么？
開發團隊預測在這次 Sprint 中要開發的功能。產品負責人講解 Sprint 的目標以及達成該目標所需完成的產品待辦列表項。整個 Scrum 團隊協同工作來理解 Sprint 的工作。
Sprint 會議的輸入是產品待辦列表、最新的產品增量、開發團隊在這個 Sprint 中能力的預測以及開發團隊的以往表現。開發團隊自己決定選擇產品待辦列表項的數量。只有開發團隊可以評估接下來的 Sprint 可以完成什么工作。
在Sprint 計劃會議中，Scrum 團隊還草擬一個 Sprint 目標。Sprint 目標是在這個 Sprint 通過實現產品待辦列表要達到的目的，同時它也為開發團隊提供指引，使得開發團隊明確開發增量的目的。
話題二: 如何完成所選的工作？
在設定了 Sprint 目標并選出這個 Sprint 要完成的產品待辦列表項之后，開發團隊將決定如何在 Sprint 中把這些功能構建成“完成”的產品增量。這個 Sprint 中所選出的產品待辦列表項加上交付它們的計劃稱之為 Sprint 待辦列表。
開發團隊通常從設計整個系統開始，到如何將產品待辦列表轉換成可工作的產品增量所需要的工作。工作有不同的大小，或者不同的預估工作量。然而，在 Sprint 計劃會議中，開發團隊已經挑選出足夠量的工作，以此來預估他們在即將到來的 Sprint 中能夠完成。在 Sprint 計劃會議的最后，開發團隊規劃出在 Sprint 最初幾天內所要做的工作，通常以一天或更少為一個單位。開發團隊自組織地領取 Sprint 待辦產品列表中的工作，領取工作在 Sprint 計劃會議和 Sprint 期間按需進行。
產品負責人能夠幫助解釋清楚所選定的產品待辦列表項，并作出權衡。如果開發團隊認為工作過多或過少，他們可以與產品負責人重新協商所選的產品待辦列表項。開發團隊也可以邀請其他人員參加會議，以獲得技術或領域知識方面的建議。
在 Sprint 計劃會議結束時，開發團隊應該能夠向產品負責人和 Scrum Master 解釋他們將如何以自組織團隊的形式完成 Sprint 目標并開發出預期的產品增量。
Sprint 目標
Sprint 目標是在當前 Sprint 通過實現產品待辦列表要達到的目的。它為開發團隊提供指引，使得團隊明確為什么要構建增量。Sprint 目標在 Sprint 計劃會議中確定。Sprint 目標為開發團隊在 Sprint 中所實現的功能留有一定的彈性。所選定的產品待辦列表項會提供一個連貫一致的功能，也即是 Sprint 目標。Sprint 目標可以是任何其他的連貫性來促使開發團隊一起工作而不是分開獨自做。
開發團隊必須在工作中時刻謹記 Sprint 目標。為了達成 Sprint 目標，需要實現相應的功能和實施所需的技術。如果所需工作和預期的不同，開發團隊需要與產品負責人溝通協商 Sprint 待辦列表的范圍。
每日 Scrum 站會
每日 Scrum 站會是開發團隊的一個以 15 分鐘為限的事件。每日 Scrum 站會在 Sprint 的每一天都舉行。在每日 Scrum 站會上，開發團隊為接下來的 24 小時的工作制定計劃。通過檢視上次每日 Scrum 站會以來的工作和預測即將到來的 Sprint 工作來優化團隊協作和性能。每日 Scrum 站會在同一時間同一地點舉行，以便降低復雜性。 開發團隊借由每日 Scrum 站會來檢視完成 Sprint 目標的進度，并檢視完成 Sprint 待辦列表的工作進度趨勢。每日 Scrum 站會優化了開發團隊達成 Sprint 目標的可能性。每天，開發團隊應該知道如何以自組織團隊來協同工作以達成 Sprint 目標，并在 Sprint 結束時開發出預期中的增量。
會議的結構由開發團隊設定。如果會議專注于達成 Sprint 目標的進展，開發團隊可以采用不同的方式進行。一些開發團隊會以問題為導向來開會，有些開發團隊會基于更多的討論來開會。以下為示例：
- 昨天，我為幫助開發團隊達成 Sprint 目標做了什么？
- 今天，我為幫助開發團隊達成 Sprint 目標準備做什么？
- 是否有任何障礙在阻礙我或開發團隊達成 Sprint 目標？
開發團隊或者開發團隊成員通常會在每日 Scrum 站會后立即聚到一起進行更詳細的討論，或者為 Sprint 中剩余的工作進行調整或重新計劃。 Scrum Master 確保開發團隊每日站會如期舉行，但開發團隊自己負責召開會議。Scrum Master 教導開發團隊將每日 Scrum 會議時間控制在 15 分鐘內。 每日 Scrum 站會是開發團隊的內部會議。如果有開發團隊之外的人出席會議，Scrum Master 必須確保他們不會干擾會議進行。 每日 Scrum 站會增進交流溝通、減少其他會議、發現開發過程中需要移除的障礙、突顯并促進快速地做決策、提高開發團隊的認知程度。這是一個進行檢視與適應的關鍵會議。
Sprint 評審會議
Sprint 評審會議在 Sprint 快結束時舉行 ，用以檢視所交付的產品增量并按需調整產品待辦列表。在 Sprint 評審會議中，Scrum 團隊和干系人協同討論在這次 Sprint 中所完成的工作。根據完成情況和 Sprint 期間產品待辦列表的變化，所有參會人員協同討論接下來可能要做的事情來優化價值。這是一個非正式會議，并不是一個進度匯報會議，演示增量的目的是為了獲取反饋并促進合作。
對于長度為一個月的 Sprint 來說，評審會議時間最長不超過 4 小時。對于較短的 Sprint 來說，會議時間通常會縮短。Scrum Master 要確保會議舉行，并且每個參會者都明白會議的目的。Scrum Master 教導每位參會者遵守時間盒的規則。
Sprint 評審會議包含以下內容：
? 產品負責人邀請 Scrum 團隊和主要的干系人參加會議；
? 產品負責人說明哪些產品待辦列表項已經“完成”和哪些沒有“完成”；
? 開發團隊討論在 Sprint 期間哪些工作做的很好，遭遇到什么問題以及問題是如何解決的；
? 開發團隊演示“完成”的工作并解答關于所交付增量的問題；
? 產品負責人討論當前的產品待辦列表的情況。他／她根據到目前為止的進度來預測可能的目標交付日期（如果有需要的話）；
? 參會的所有人就下一步的工作進行探討，這樣， Sprint 評審會議就能夠為接下了的 Sprint 計劃會議提供有價值的輸入信息；
? 評審市場或潛在的產品使用方式所帶來的接下來要做的最有價值的東西的改變； 同時，
? 為下個預期產品功能或產品能力版本的發布評審時間表、預算、潛力和市場。
Sprint 評審會議的結果是一份修訂后的產品待辦列表，闡明很可能進入下個 Sprint 的產品待辦列表項。產品待辦列表也有可能為了迎接新的機會而進行全局性地調整。
Sprint 回顧會議
Sprint 回顧會議是 Scrum 團隊檢視自身并創建下一個 Sprint 改進計劃的機會。
回顧會議發生在 Sprint 評審會議結束之后，下個 Sprint 計劃會議之前。對于長度為一個月的 Sprint 來說，回顧會議時間最長不超過 3 小時。對于較短的 Sprint 來說，會議時間通常會縮短。Scrum Master 要確保會議舉行，并且每個參會者都明白會議的目的。
Scrum Master 確保會議是積極的和富有成效的。 Scrum Master 教導大家遵守時間盒的規則。Scrum Master 作為 Scrum 過程的責任者，作為團隊的一員參加該會議。
Sprint 回顧會議的目的在于：
? 檢視前一個 Sprint 中關于人、關系、過程和工具的情況如何；
? 找出并加以排序做得好的和潛在需要改進的主要方面； 同時，
? 制定改進 Scrum 團隊工作方式的計劃。
Scrum Master 鼓勵 Scrum 團隊在 Scrum 的過程框架內改進開發過程和實踐，使得他們能在下個 Sprint 中更高效更愉快。在每個 Sprint 回顧會議中，如果適用并且不與產品或組織標準相沖突，Scrum 團隊計劃不同的方式通過改進工作過程或調整“完成”的定義來提高產品質量。
在 Sprint 回顧會議結束時，Scrum 團隊應該明確接下來的 Sprint 中需要實施的改進。在下一個 Sprint 中實施這些改進是基于 Scrum 團隊對自身的檢視而做出的適當調整。雖然改進可以在任何時間執行，Sprint 回顧會議提供了一個專注于檢視和適應的正式機會。
SCRUM 工件
Scrum 的工件以不同的方式表現工作任務和價值，可以用來提供透明以及檢視和適應的機會。Scrum 所定義的工件是特別地設計的，是為了給關鍵信息提供最大透明化，因此每個人對工件都需要有相同的理解。
產品待辦列表
產品待辦列表是一份涵蓋產品中已知所需每項內容的有序列表，它是產品需求變動的唯一來源。產品負責人負責管理產品待辦列表的內容、可用性和排序。
產品待辦列表永遠是不完整的。最早開發的產品待辦列表列舉最初所知的以及理解最透徹的需求。產品待辦列表會隨著產品及其應用環境的改變而演進。產品待辦列表是動態的，需要持續更新以反映出產品需要什么來保持其適用性、競爭力和有用。如果產品存在，產品待辦列表也就同樣存在。
產品待辦列表列出所有的特性、功能、需求、增強和修復等對未來要發布的產品進行的改變。產品待辦列表項具有這些屬性：描述、次序、估算和價值。產品待辦列表項通常包括測試描述，將在“完成”時證明其完整性。
隨著產品的使用、價值的獲取和獲得市場的反饋，產品待辦列表會成長為更大和更詳盡的列表。因為需求永不停止改變，所以產品待辦列表就如一份活的工件。業務需求、市場形勢或者技術的變化都會引起產品待辦列表的改變。
多個 Scrum 團隊常常會一起參與對同一產品的開發。一個產品只有一個產品待辦列表用于描述下一步產品開發工作。那么這就可能需要使用能夠對產品待辦列表項進行分組的屬性。
產品待辦列表精化指的是為產品待辦列表項增添細節、估算和排序的動作。這是一個持續的過程，產品負責人和開發團隊協同工作在產品待辦列表項的細節上。在產品待辦列表精化過程中，產品待辦列表項被重新評審和修改。Scrum 團隊決定如何來完成精化以及何時來完成。精化的工作通常占用開發團隊不超過 10% 的產能。然而，產品負責人或者其他人在產品負責人的斟酌下，產品待辦列表項可以在任何時間來更新。
排序越高的產品待辦列表項通常比排序低的更清晰同時包含更多細節。根據更清晰的內容和更詳盡的細節信息就能做出更為準確的估算；同樣，排序越低，則細節信息越少。產品待辦列表項中那些即將會占用開發團隊下一個 Sprint 大部分時間的項會被加以精化，因此，任一產品待辦列表項都能夠在 Sprint 的時間盒期限內適當地“完成”。這些能夠被開發團隊在一個 Sprint 中“完成”的產品待辦列表項稱為“準備就緒”，它們將作為 Sprint 計劃會議中的待選產品列表項。產品待辦列表項的足夠透明程度通常要經過上述的精化活動來獲得。 開發團隊負責所有估算工作。產品負責人可以通過幫助開發團隊更好地理解需求，并根據情況權衡取舍來影響他們，但是最終估算是由開發團隊決定的。
監控目標實現的進度
在任何時刻，達成目標的剩余工作是可以累計的。產品負責人至少在每個 Sprint 評審會議中都必須跟蹤剩余工作總量。產品負責人比較這次的剩余工作量與之前 Sprint 評審會議時的剩余工作量，來評估在期望的時間點達成目標的進度。這個信息對所有的干系人都是透明的。 各種不同趨勢走向的實踐已經被使用在預測進度方面，例如，燃盡圖（burn-downs）、燃燒圖（burn-ups）或者累積流圖（cumulative flows）。這些工具都被證實是有用的。然而，它們并不能用來取代經驗主義的重要性。在復雜的環境中，未來將要發生的事是無法預知的。只有已經發生的事情才能用來做前瞻性的決策。
Sprint 待辦列表
Sprint 待辦列表是一組為當前 Sprint 選出的產品待辦列表項，同時加上交付產品增量和實現 Sprint 目標的計劃。Sprint 待辦列表是開發團隊對于下一個產品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的預測。 Sprint 產品待辦列表將開發團隊用來達成 Sprint 目標的所有工作變得清晰可見。為了確保持續改進，它至少包括一項在先前回顧會議中確定下來的高優先級過程改進。 Sprint 產品待辦列表是擁有足夠細節的計劃，任何進度的變化可以在每日 Scrum 站會中清晰地看到。開發團隊在 Sprint 期間修改 Sprint 待辦列表，使得 Sprint 待辦列表在 Sprint 期間涌現。涌現發生在開發團隊按計劃開展工作并學習到更多的關于哪些工作是達成 Sprint 目標所必需的工作時。 當新工作出現時，開發團隊需要將其加入到 Sprint 待辦列表中去。隨著工作的執行或完成，剩余的工作量被估算并更新。當計劃中的某個部分失去開發意義，就可以將其移除。在 Sprint 期間，只有開發團隊可以改變 Sprint 待辦列表。Sprint 待辦列表是高度可見的，是對開發團隊計劃在當前 Sprint 內工作完成情況的實時反映，該列表由開發團隊全權負責。
監控 Sprint 進度
在 Sprint的任何時間點都可以計算 Sprint 待辦列表中所有剩余工作的總和。開發團隊至少在每日 Scrum 站會時跟蹤剩余的工作量，預測達成 Sprint 目標的可能性。通過在 Sprint 中不斷跟蹤剩余的工作量，開發團隊可以管理自己的進度。
增量
增量是一個 Sprint 完成的所有產品待辦列表項的總和，以及之前所有 Sprint 所產生的增量的價值總和。在 Sprint 的最后，新的增量必須是“完成”的，這意味著它必須可用并且達到了 Scrum 團隊“完成”的定義的標準。增量是在 Sprint 結束時支持經驗主義的可檢視的和已完成的產品組成部分。增量是邁向愿景或目標的一步。無論產品負責人是否決定發布它，增量必須可用。
工件透明
Scrum 依賴于透明。優化價值和控制風險的決定都是基于所獲知的工件狀態。當工件的狀態是完全透明時，這些做出的決定才有一個堅實的基礎；當工件的狀態是不完全透明時，這些做出的決定就會有瑕疵，而價值也可能因此遭受損失，同時風險也可能會因此而增加。
Scrum Master 必須和產品負責人、開發團隊和其他相關人員一起合作，以確保所有工件都是完全透明的。有些實踐就是為應對不完全透明的狀態而生的，Scrum Master 必須幫助每個人，讓他們能夠在遇到不透明的情況下采取最合適的實踐。Scrum Master 能夠通過檢視工件、嗅探模式、傾聽周圍的聲音以及觀察預期和實際結果的差異來發現不完全透明。
Scrum Master 的職責就是和 Scrum 團隊以及組織一起合作增加工件的透明化。這一工作通常包括學習、說服和改變。 透明化不會在一夜之間發生，但是這是一條必經之路。
“完成”的定義
當產品待辦列表項或增量被描述為“完成”時，每個人都必須理解“完成”意味著什么。雖然在不同Scrum團隊之間或許會存在顯著差異，但是每個團隊成員必須對完成工作意味著什么有相同的理解以便確保透明化。這就是 Scrum 團隊的“完成”定義，用來評估產品增量是否完成。
這一定義也同時被用來指導開發團隊了解在Sprint計劃會議時能夠選擇多少產品待辦列表項。每個 Sprint 的目標在于交付符合 Scrum 團隊當前“完成”的定義的潛在可交付功能增量。 開發團隊在每個 Sprint 都交付產品功能增量。這一增量是可用的，所以產品負責人可以選擇立即發布它。如果“完成”的定義對增量來說是開發組織的慣例、標準或指南，那么所有Scrum團隊都必須遵守它，以此為最低標準。 如果增量“完成”的定義不是開發組織的慣例，那么 Scrum 團隊中的開發團隊就必須制定適合于產品的“完成”的定義。如果系統或產品發布由多個 Scrum 團隊一起開發，那么所有 Scrum 團隊中的開發團隊必須一起參與制定“完成”的定義。
每個增量都添加至之前的所有增量上，并且經過徹底地測試，以此確保整合在一起的所有增量都能工作。
隨著團隊的成熟，“完成”的定義會擴大，包含更為嚴格的標準來保證更高的質量。當使用新定義時，在先前“完成”增量中可能會發現尚需完成的工作。任何產品或系統都應該對其上面開發的工作有“完成”的定義。
結束語
Scrum 是免費的，在本指南中提供。Scrum 的角色、事件、工件和規則是不可改變的。雖然只實施部分的 Scrum 是可能的，但這樣就不是 Scrum 了。Scrum 只以整體形式而存在，唯其如此才能作為其他技術、方法和實踐的容器運作良好。
致謝
人們
千千萬萬對 Scrum 作出貢獻的人中，我們要特別感謝那些在其最初提供幫助的人：與Jeff Sutherland一道工作的Jeff McKenna 和 John Scumniotales，與Ken Schwaber 一道工作的Mike Smith 和 Chris Martin。在隨后的幾年中，許多人都作出了貢獻，沒有他們的幫助，Scrum 不會被提煉至如今這般。
歷史
Ken Schwaber 和 Jeff Sutherland在1995年前致力于 Scrum ，在1995年 OOPSLA 會議上聯合公開演講 Scrum。這次演講本質上是 Ken 和 Jeff 在之前數年運用 Scrum 積累所得的記錄，首次公開提出 Scrum 的正式定義。
Scrum 的歷史在別處描述過。我們對首批嘗試和提煉 Scrum 的公司：Individual，Inc.， Newspage，Fidelity Investments和 IDX （現為 GE 醫療）表示致敬。
Scrum 指南記錄了 Jeff Sutherland 和 Ken Schwaber 在 Scrum 已超過 20 多年的開發、演進和培育。其他一些資源從模式、過程和見解方面為 Scrum 框架提供了補充，提高了生產效率、價值、創造力和對結果的滿意度。
譯者致謝
本簡體中文指南（ 2017版 ）由上述致謝的開發者所提供的英文原版（2017版）翻譯而來。
譯者：周建成，敏捷教練
總結
以上是生活随笔為你收集整理的SCRUM敏捷开发官方权威指南的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Sharding-JDBC（三）3.1.
- 下一篇： 什么是SCRUM敏捷开发