最新版Scrum指南已由来自Scrum, Inc的Scrum共同发明人Ken Schwaber和来自Scrum.org的Jeff Sutherland联手发布。上一版发布于2013年，此版最大的变化是包含了Scrum价值观 (Scrum Values)。
Scrum指南包含有关Scrum的权威指南，「整个游戏的规则」。Schwaber和Sutherland通过合作定期更新该Scrum指南，并通过Scrum指南网站的User Voice区域响应来自社区的反馈。新版发布后，InfoQ与Schwaber谈到了最新版中的改动和未来的计划。
Scrum指南有什么更新?
Scrum指南是独立于Scrum.org，由Scrum的发明人Jeff Sutherland和我共同管理的。我们成立了一个由Scrum专家组成的活跃社区，大家会用Scrum指南为自己的工作提供基本指导，并不断通过指南网站上的 User Voice 区域发表自己的声音，为指南的后续发布和反馈提供意见。
为Scrum指南增加有关价值观的内容是呼声最高的意见，投票数量甚至是其他反馈的三倍以上。因此Jeff和我听取大家意见增加了这些内容。这些内容不仅基于Scrum专家的反馈，而且专业素质也需要具备相应的价值观，并要通过价值观帮助大家体现Scrum和软件开发工作的专业性。颁布并逐渐接受后，这些价值观可以为敏捷软件开发打造一种文化。
增加Scrum价值观内容
包括承诺、勇气、专注、开放，以及尊重。整个Scrum团队也会遵循这套价值观，因为这套价值观是整个团队整体获得成功的关键。另外指南会介绍Scrum团队需要在什么情况下体现和遵守有关承诺、勇气、专注、开放，以及尊重的价值观，按照Scrum有关透明度、检查，以及适应性的信条赢得每个人的信任。在参与Scrum的活动、角色，以及开发工作过程中，Scrum团队成员都需要学习和探索这些价值观。
Scrum指南 (Scrum Guide)
Scrum的成功运用取决于人们能否变得更专精于这五大价值。大家需要针对Scrum团队目标的实现做出个人承诺。我们鼓励Scrum团队成员做正确的事，迎接工作中的艰巨挑战。大家都专注于冲刺（Sprint）工作以及Scrum团队的目标。Scrum团队和有关人员同意对所有工作以及工作中面临的挑战持开放态度。作为有能力的个人，Scrum团队成员也会相互尊重。
Scrum Guide 指南的目的
Scrum 是一個框架，這框架適用於開發，交付，與持續支援具有錯綜複雜的產品。這份指南包含 Scrum 的定義，其中定義涵蓋了 Scrum 中的角色，活動，產出物，與它們之間如何進行的規則。Scrum 是由 Ken Schwaber 和 Jeff Sutherland 共同發展出來的；Scrum 指南也是由他們所撰寫及提供，他們是 Scrum 指南背後的共同推手。
Scrum 的定義
Scrum （名詞）：一個框架，人們可以運用這個框架來處理錯綜複雜的調適性問題，善用生產力與創意來交付盡可能最高價值的產品。
Scrum 是：
● 輕量的
● 淺顯易懂的
● 難以精通
Scrum 是一個流程框架，從 1990 年代初期它就被用來管理生產錯綜複雜的產品。Scrum 不是一種流程，一個技巧，或明確既定的方法。倒不如説 Scrum 是一個框架，在其中你可以使用各種不同的流程與技巧。運用 Scrum 可以清楚的呈現不同產品管理方法和工作技巧的功效，因此你可以持續改善產品，團隊，還有工作環境。
Scrum 框架中包含了 Scrum Teams 和他們相關的角色，活動，產出物，和規則。每個框架中的組成都有特定的目的，也都是讓 Scrum 成功和運行的必要條件。
Scrum 規則把角色，活動和產出物整合在一起，也主宰了各個組成之間的關係和互動。這整份文件都是在描敘 Scrum 規則。
各種使用 Scrum 框架的具體策略有很大的差異，這些策略不在這指南中描述。
Scrum 的運用
Scrum 一開始是為了管理和開發產品而發展出來的。從 1990 年代初期開始，Scrum 就在全世界被大量的運用在：
- 研究和辨識出市場，技術，產品性能的可行性;
- 開發產品和加強功能;
- 發佈產品和加強功能，頻率高到一天可能發佈許多次;
- 開發和支援雲端服務（線上，高安全性，隨時存取）和其他營運環境來幫助產品的運用，
- 以及支援和更新產品。
Scrum 已經被使用於開發軟體，硬體，韌體，互動的網路，自駕車，學校，政府，行銷，管理組織的營運，還有幾乎所有我們日常生活中的事物上，不論是個人或是社會。
在科技，市場，環境都日趨錯綜複雜，而且各個因素之間的互動快速增加的情況下，每天都可以看到運用 Scrum 來處理錯綜複雜的問題的效用。
Scrum 被證明在迭代和漸進式的知識轉移中特別有效。目前 Scrum 已經被廣泛的使用在組織內的產品，服務，和管理。
Scrum 的精華在於小型的團隊。每個團隊都具有高度彈性和調適性。這些團隊從事開發，發佈，營運，和支援的工作，不論是一個團隊，一些團隊，許多團隊或是更多串連在一起的團隊所組成，都擁有這些優勢，他們藉由精細複雜的開發架構和鎖定發佈環境來協同合作和交互運作。
當 Scrum Guide 中使用「開發 （develop）」這個字的時候，指的是從事複雜的工作，如上面所陳述到的那些類型。
Scrum 的理論 (Scrum 3 Pillars)
Scrum 是立基於經驗導向的流程控制理論，或是經驗主義。經驗主義立論於知識來自於經驗和依照已知的資訊來下判斷。Scrum 使用迭代和逐步 Increment 的方式，來最大化可預測性和控制風險。
有三根支柱支撐了所有經驗導向的流程控制的實行：透明性，檢視性，調適性。
透明性
負責產生成果的人員必須清晰地看見流程中重要的部分，這些部分被共同的標準來定義，所以觀看的人能得到一致的認知，這就是透明性。
例如：
● 所有的參與者對該流程都有共同的語言；以及
● 真正執行的人員和檢視 Increment 成果的人員，需要對「完成」之定義，有一個共同的認知。
檢視性
Scrum 的成員必須經常檢視 Scrum 的產出物和 Sprint 目標的進度來檢測意料之外的變數。他們的檢視不應該頻繁到會阻礙工作的進行。最有效益的檢視方式，是由盡職且擁有技能的檢視者在工作的當下進行。
調適性
如果檢視者判斷流程中的某些部分超出了可以接受的範圍，且會造成產品不被接受，就必須調整當下的流程或使用材料。調整必需越快越好來減少未來更多的偏差。
在 Scrum 中規定了四個幫助檢視性和調適性的正式活動，在 Scrum 活動的章節會介紹：
● Sprint Planning
● Daily Scrum
● Sprint Review
● Sprint Retrospective
Scrum 價值觀 (Scrum 5 Values)
當 Scrum Team 體現和活化承擔，勇氣，專注，開放和尊重這五種價值觀時，Scrum 的三根支柱：透明性，檢視性，調適性就會出現並幫助大家建立信任。隨著 Scrum Team成員從事 Scrum 角色，活動和產出物的過程中，他們就會學習和探索這些價值。 要成功運用 Scrum 取決於成員是否精通並融入這五個價值。成員個人承諾會達到 Scrum Team 的目標，Scrum Team members 有勇氣做對的事情和處理艱難的問題，每個人專注在 Sprint 的工作和 Scrum Team 的目標上，Scrum Team 和利害關係人同意對工作和工作上的挑戰保持開放的心態，Scrum Team members 互相尊重對方是有能力和獨立的人。
Scrum Team
Scrum Team 由 Product Owner，Development Team 和一位 Scrum Master 組成。Scrum Teams 是一個自我組織和跨職能的團隊。自我組織的團隊會自行選擇最好的方式來完成工作，而不是被團隊外的人指示如何做。跨職能的團隊不需依靠非團隊成員而擁有所有完成工作所必備的能力。Scrum 中的團隊模式是設計用來將彈性，創意，和生產力最大化。Scrum Team必須證明自己在前述的情況和錯綜複雜的工作中越來越有效。
Scrum Teams 用迭代和逐步 Increment 的方式交付產品，將回饋的機會最大化。用逐步Increment 的方式交付「完成」的產品，可以確保一直提供一個潛在可用的產品版本。
The Product Owner
Product Owner 負責將產品的價值最大化，而價值來自於 Development Team 的工作成果。如何做到這點可能在每個組織，Scrum Teams，或個人，都差異很大。
Product Owner 這個角色只能由一個人來擔任，專門負責管理 Product backlog。Product backlog 管理包含：
- 清楚的表達 Product Backlog items；
- 針對 Product backlog 上的事項進行排序來達到最好的目標和使命；
- 將 Development Team 工作所產生的價值最佳化
- 確保 Product backlog 是每個人都可以看見的，是有透明度的，以及清晰瞭解的，而且可以顯示出 Scrum Team 接下來要做的事；和
- 確保 Development Team 對 Product Backlog 的了解有到達所需要的程度
Product Owner 可以自己做以上的工作，或由 Development Team 來做。但不管如何都是由 Product Owner 當責。
Product Owner 是由一個人來擔任，而不是一個委員會。Product Owner 可能代表一個委員會對於 Product backlog 的期望要求，但任何人想要改變 Product Backlog 的優先順序，都需要經過 Product Owner 的同意。
要讓 Product Owner 成功，整個組織必須尊重他/她的決定。Product Owner 對於Product Backlog 內容和順序之決定是透明的，沒有人可以強迫 Development Team 做 Product backlog 以外的需求。
The Development Team
Development Team 由一群專業人士組成，他們可以在每個 Sprint 結束時交付「完成」潛在可發佈的產品 Increment。「完成」的產品 Increment 必須在 Sprint Review 上呈現。只有 Development Team 的成員可以產生產品 Increment。
組織建立並授權 Development Team，讓他們可以自行組織和管理他們自己的工作。所達成的綜效可讓 Development Team 整體的效率和效能達到最大化。
Development Team 有以下的特性：
- 他們是自組織的。沒有人（甚至是 Scrum Master）可以對 Development Team 下指導棋，告訴他們如何把 Product backlog 轉換成潛在可發佈的產品 Increment；
- Development Team 是跨職能的，擁有產出產品 Increment 所需要的所有技能；
- Scrum 認為 Development Team members 沒有職稱，不管個人所做的工作是什麼；
- Scrum 認為 Development Team 中沒有小團隊，不管需要解決的是什麼領域，如測試，架構，營運或商業分析；和
- Development Team members 雖然可能各自有專精的技能和領域，但仍是由Development Team 整體來當責。
Development Team 的大小
最理想的 Development Team 大小，是小到足夠靈活而且大到能夠完成 Sprint 內重大的工作。少於三個人的 Development Team member 之間的互動會減少，以至於只能提升小部分的生產力。小一點的 Development Team 可能會在 Sprint 中遇到技能的限制，使得Development Team 無法交付潛在可發佈的產品 Increment。如果成員多過九個人則會造成太多的協調。大的 Development Teams 產生太多的複雜性，而使得經驗導向的流程沒辦法那麼有效。Product Owner 和 Scrum Master 的角色並不包含在 Development Team人數中，除非他們也執行 Sprint Backlog 上的工作。
Scrum Master
Scrum Master 依照 Scrum 指南中的遊戲規則來負責推廣和支持 Scrum。Scrum Master 幫助每個人了解 Scrum 的理論，實務，規則和價值觀，來達成推動 Scrum。
對於 Scrum Team 來說，Scrum Master 是一個僕人式的領導。Scrum Master 幫助Scrum Team 外的人了解哪些與Scrum Team 之間的互動是有幫助的，而哪些是沒有幫助的。Scrum Master 幫助每個人改變這些互動的方式，讓 Scrum Team 產生的價值能夠最大化。
Scrum Master 對 Product Owner 提供的服務
Scrum Master 對Product Owner 提供多方面的服務，包含：
- 確保 Scrum Team 的每位成員都盡可能地理解目標，範圍與產品領域；
- 找出有效管理 Product backlog 的技巧；
- 幫助 Scrum Team 理解為什麼需要清楚簡潔的 Product Backlog items；
- 在經驗導向的環境中理解產品規劃；
- 確保 Product Owner 知道如何安排 Product backlog 來讓價值最大化；
- 理解和實踐敏捷；與
- 當需要或被要求時，引導 Scrum 活動的進行。
Scrum Master 對 Development Team 提供的服務
Scrum Master 對 Development Team 提供多方面的服務，包含：
- 作為教練指導 Development Team如何自我組織和跨職能；
- 幫助 Development Team 創造高價值的產品；
- 移除 Development Team 在過程中的障礙；
- 當需要或被要求時，引導 Scrum 活動的進行；與
- 在組織環境還沒有完全採用與理解 Scrum 的情況下，作為教練指導 Development Team。
Scrum Master 對組織提供的服務
Scrum Master 對組織提供多方面的服務，包含：
- 帶領和作為教練指導組織來採用 Scrum；
- 規劃 Scrum 在組織內的實施；
- 幫助員工和利害關係人理解及制定 Scrum 與經驗導向的產品開發；
- 造成改變來增加 Scrum Team 的生產力；
- 與其他 Scrum Master 一起合作來加強組織內 Scrum 應用的有效性。
Scrum 的活動
Scrum 規定了幾項活動來創造規律性，以此來減少其它 Scrum 未定義的會議。這些活動都是有時間盒限制的，也就是在某個時間長度內必須要完成。當 Sprint 開始，Sprint 的長度就固定下來了，不可以縮短或是延長。剩下的活動在達成其目的後就可以結束了，以確保在過程中只使用了適當的時間而不會造成流程中的浪費。
Sprint 本身包含了其他的活動，除了 Sprint 本身之外，每次活動都是用來檢視與調適某些事情的正式機會，這些活動都是特別設計來促成嚴格的透明性與檢驗性。遺漏其中的任何一種活動可能導致透明性降低，檢視和調適的機會變少。
Sprint
Scrum 的核心是 Sprint，Sprint 是一個月或更短的時間盒。在 Sprint 內，會產出「完成」的，可用的，潛在可發佈的產品 Increment。Sprint 長度在整個開發過程中都是固定的，前一個 Sprint 結束後，下一個新的 Sprint 立刻接著開始。
Sprint 包括了 Sprint Planning，Daily Scrums，開發工作，Sprint Review 與 Sprint Retrospective。
在 Sprint 過程中：
- 不可以發生會危及 Sprint 目標的改變；
- 對於品質的目標不可以降低；與
- 隨著獲得了更多關於產品的細節，Product Owner 與 Development Team 之間對於範圍內要做的事可以加以澄清與重新溝通。
每個 Sprint 可視為一個不超過一個月的專案，如同其他專案一般，Sprint 是用來完成某些事情的。每個 Sprint 有著要打造些什麼的目標，而由一份設計和有彈性的計畫來引導其打造的過程，工作與最後的產品 Increment。
Sprint 被限制在一個月內，當 Sprint 時間拉的太長時，現在正在打造的東西的定義可能會發生改變，而其複雜性也許會增加，導致風險上升，Sprint 藉由至少一個月一次的檢視與調適 Sprint 目標進度來達成可預期性，也因此，Sprint 便可將成本風險限制在一個月內。
取消 Sprint
Sprint 可在時間盒限制結束前取消，但只有 Product Owner 有取消 Sprint 的權力，雖然Product Owner 的這個決定可能是來自於利害關係人，Development Team 或是 Scrum Master 的影響。
當 Sprint 目標已經變得過時，不重要的時候，就可以取消 Sprint，這可能是因為公司改變了方向或是因為市場或技術上的改變。一般而言，如果當下的情況已經變得不合理，那就應該取消 Sprint，但因為 Sprint 的時間很短，取消通常是不太合理的事情。
當 Sprint 被取消時，會檢視已經「完成」的 Product Backlog items，如果有某部分的工作已經是潛在可發佈了，Product Owner 一般會接受這些成果。而尚未完成的 Product Backlog items 會被重新估計，並放回 Product backlog 內，花在這些尚未完成的 Product Backlog 上的工作價值會流失得很快，所以需要經常不斷的重新估計來反映。
取消 Sprint 會消耗資源，因為要在新的 Sprint Planning 把每個人集合起來，重新開始新的 Sprint，Sprint 的取消會對 Scrum Team 造成重大傷害，所以並不常發生。
Sprint Planning
Sprint 內要做的事會在 Sprint Planning 中來訂定。工作計劃是由整個 Scrum Team 協同合作來制定的。
Sprint Planning 是有時間盒限制的，以一個月的 Sprint 來説，Sprint Planning 最多為八小時。對於少於一個月的 Sprint，這個會議所需的時間更短。Scrum Master 確保這個會議活動的發生，以及出席人員了解這個會議的目的。並且教導 Scrum Team 在時間盒限制內完成此會議。
Sprint Planning 回答以下問題：
- 這次 Sprint 可以發佈什麼樣的 Increment？
- 如何做才能夠達成 Increment？
第一個討論題目：這次 Sprint 能做出什麼？
Development Team 預測在這次Sprint內能開發出什麼功能。Product Owner 討論這次 Sprint 所應該達成的目標，以及完成哪些 Product Backlog items 可以達成這個目標。整個 Scrum Team 協同合作來了解 Sprint 要做的工作。
這個會議的輸入包含： Product backlog ，最近的 Increment，在 Sprint 內 Development Team的產能預測，以及 Development Team 的過去表現。從 Product backlog 之中要選出那些項目完全取決於 Development Team。只有 Development Team 可以評估即將到來的 Sprint 所能達成的事情。
在 Sprint Planning 中 Scrum Team 同時草擬本次的 Sprint 目標。Sprint 目標經由實作Product Backlog 來達成，同時指引 Development Team 知道為何要做這次的 Increment。
第二個討論題目：如何完成所選的工作？
在設定 Sprint 目標與選出 Product Backlog Items 之後，Development Team 決定如何在這次 Sprint 內，建造這個功能來做出一個「完成」的產品 Increment。Sprint Backlog 指的是：這次 Sprint 所選的 Product Backlog items 加上如何交付它們的計劃。
Development Team 通常從系統的設計開始，到找出那些工作可以將 Product backlog 轉換成一個可運作的產品 Increment。工作通常有不同的大小，或不同的預估工作量。然而，在 Sprint Planning 中，Development Team 只預測他們在本次 Sprint 要完成的工作量即可。在 Sprint Planning 結束之際，Development Team 應該已經規劃出在 Sprint 的前幾天內所要做的工作，通常以一天或更少為一個單位。不管是在 Sprint 計劃會議中以及在Sprint 期間內，Development Team 自我組織的來承擔 Sprint Backlog 的工作。
Product Owner 能夠幫助釐清所選定的 Product Backlog items 以及做出折衷。如果 Development Team 發現 Product Backlog 的工作內容太多或太少，他們可以與 Product Owner 重新商討所選的 Product Backlog items。Development Team 也可以邀請在技術領域或者其它領域的專家一起來參加會議提供建議。
在 Sprint Planning 結束之際，Development Team 應該能夠解釋給 Product Owner 以及 Scrum Master，他們要如何自我組織來完成 Sprint 目標以及開發出預定的 Increment。
Sprint 目標
Sprint 目標是實作 Product backlog 過程中所必須達到的目的。它指引 Development Team 爲什麼要做這個 Increment。Sprint 目標是在 Sprint Planning 中產生的。對於在 Sprint 內要實作的功能，Sprint 目標提供了 Development Team 要實作哪些功能的彈性。這些被選定的 Product Backlog items 提供一個連貫的功能，而這個功能即可成為 Sprint 目標。Sprint 目標也可以是任何有連貫性的工作，這些工作讓 Development Team 一起合作，而不是讓他們各自做各自的。
當 Development Team 工作時會牢記 Sprint 目標。Development Team 會實作出需要的功能和工藝來達到 Sprint 目標。如果要做的事情和 Development Team 預期的不同，他們會跟Product Owner 協同合作來溝通商量本次 Sprint Backlog 之範圍。
Daily Scrum
Daily Scrum 是一個針對 Development Team 的活動，其時間盒限制是 15 分鐘，此會議在 Sprint 期間內每日召開。在這個會議裡，Development Team 會規劃未來 24 小時的工作。透過檢視前次 Daily Scrum 後的工作及展望接下來的Sprint工作，將會逐步優化團隊協同合作和表現。Daily Scrum 在同一時間與地點舉行來降低其複雜性。
Development Team 藉由 Daily Scrum 來檢視達成 Sprint 目標的進度，以及檢視所完成的Sprint Backlog 進度的趨勢。Daily Scrum 優化了 Development Team 達到 Sprint 目標的可能性。每一天，Development Team 都應該理解如何以一個自我組織的團隊來一起完成Sprint 目標，並在 Sprint 結束時創造出符合預期的 Increment。 會議的架構由 Development Team決定，只要聚焦在達成 Sprint 目標的進度上，都可以用不同的方式進行。 一些 Development Team 會使用提出問題的方式，而有一些則會以討論的方式進行。以下是一個可以使用的範例：
- 我昨天做了什麼事來幫助 Development Team 達到 Sprint 目標?
- 我今天要做什麼事來幫助 Development Team 達到 Sprint 目標?
- 我是否有察覺到任何障礙使得我或者 Development Team 無法達到 Sprint 目標?
Development Team 或團隊成員經常在 Daily Scrum 後再立即會面，以便進行詳細的討論，調適或重新規劃 Sprint 的其餘工作。
Scrum Master 確保 Development Team 有進行 Daily Scrum，但 Development Team 要負責召開此會議。 而 Scrum Master 要教導 Development Team 將 Daily Scrum 保持在時間盒限制 15 分鐘內完成。
Daily Scrum 是 Development Team 的內部會議。 如果有其他人在場，Scrum Master 要確保他們不會打擾到會議的進行。
Daily Scrums 改善溝通品質，淘汰其他會議，發現並移除開發上的障礙，突顯及促進快速決策，還有提升 Development Team 的知識水平。 這是一個用來做為檢視和調適的重要關鍵會議。
Sprint Review
Sprint Review 是在 Sprint 結束時舉行，目的是檢視 Increment以及在必要時調適 Product Backlog。在 Sprint Review 中，Scrum Team 和利害關係人一起協同合作檢視在 Sprint 中所完成的事項。依照這些事項和在 Sprint 過程中 Product Backlog 的變動，參與者一起協同合作討論接下來能做完哪些最有價值的事情。這是一個正式但輕鬆的會議，並不是一個進度回報的會議，關於 Increment 的展示是為了引發意見的反饋和提升協同合作。
對於為期一個月的 Sprint 來説，這是一個最多四個小時的會議。 在長度更短的 Sprint，通常所需的時間更短。Scrum Master 確保這個會議活動的發生，以及出席人員了解這個會議的目的。Scrum Master 教導參與的每個人如何在時間盒限制內完成會議。 Sprint Review 包含以下要件：
- 參與者包含 Scrum Team 和 Product Owner 邀請的主要利害關係人；
- Product Owner 解釋哪些 Product Backlog items 已經「完成」，與哪些尚未「完成」；
- Development Team 討論在 Sprint 中進行順利的事項，遇到那些問題與及這些問題如何被解決；
- Development Team 展示已「完成」的工作並回答關於 Increment 的問題；
- Product Owner 討論目前的 Product backlog 的現況，他/她（視情況而定）根據到目前為止的進度來預測可能的的交付日期；
- 整個團體協同合作來決定下一步要做什麼，所以 Sprint Review 提供了有價值的資訊給接下來的 Sprint Planning 當作輸入；
- 檢視市場或潛在的產品使用情況是否改變了接下來最有價值的下一步；與
- 檢視接下來期待會發布的產品功能的時間，預算，潛力，和市場。 Sprint Review 的結果，是一個修正過的 Product backlog ，在清單中定義了在下個 Sprint 可能會做的Product Backlog items。 Product backlog 亦可以調整來因應新的機會。
Sprint Retrospective
Sprint Retrospective 提供 Scrum Team 一個自我檢視的機會，並建立一個改進計劃以便在下一個 Sprint 中落實。 Sprint Retrospective 召開在 Sprint Review 之後，下一個 Sprint Planning 之前。對於為期一個月的 Sprint 來説，這是一個最多三個小時的會議。 在長度更短的 Sprint，通常所需的時間更短。
Scrum Master 確保這個會議活動的發生，以及出席人員了解這個會議的目的 Scrum Master 確保這個會議是正向積極並有成效的。 Scrum Master 教導所有人在時間盒限制內完成會議。 Scrum Master 以團隊成員的身分來參與這個會議，因為他對 Scrum 的流程當責。
Sprint Retrospective 的目的是：
- 檢視上次 Sprint 內關於人員，關係，流程和工具的情況；
- 找出並加以排序做的很好的重要事項，及具有改善潛力的事項；同時，
- 制定一個計劃來落實如何改善 Scrum Team 的工作方法。
Scrum Master 鼓勵 Scrum Team 在 Scrum 流程框架內改善其開發流程和實務，使其在下一個 Sprint 的工作中能更有效能及愉快。 在每個 Sprint Retrospective 中，Scrum Team 會規劃各種方法來提升產品的品質，在恰當且不與產品或組織標準相衝突為前提下，改善工作流程或調整「完成」之定義。
在 Sprint Retrospective 結束之際，Scrum Team 應該已經確定了在下一個 Sprint 中要實施改善的地方。 在下一個 Sprint 中執行這些改善，即是 Scrum Team 在自我檢驗後的調適。雖然改善可能在任何時間點落實，但 Sprint Retrospective 提供了一個正式的機會來專注在檢視與調適上。
Scrum 產出物 (Scrum Artifacts)
Scrum 的產出物代表了工作或價值，用以提供透明化以及檢視和調適的機會。 Scrum 所定義的產出物是專門設計用於讓關鍵資訊有最大的透明性，以便每個人對該產出物有相同的理解。
Product Backlog
Product Backlog 是產品所有已知需求的排序表。它是對產品進行任何更改的唯一需求來源。Product Owner 對 Product backlog 負責，包含其內容，可取得性和排序。
Product backlog 永遠沒有完成的一天。早期的開發僅排定了最初已知和最被理解的需求。 Product backlog 隨著產品和使用環境的演變而演化。 Product backlog 是動態的；它不斷地變化來找出什麼對產品而言是恰當的，有競爭力以及有用的。只要產品存在的一天，它的 Product backlog 也會同時存在。
Product backlog 列出了所有特性，功能，需求，改善功能和修補程式，這些事情構成了對未來要發布的產品的更新。Product Backlog items 的屬性包括了其描述，順序，估計和價值。Product Backlog items 通常包括測試描述，用來證明「完成」的完整性。
隨著產品的使用和獲得價值，以及市場提供的反饋， Product backlog 將成為更大更詳盡的列表。 需求永遠不會停止改變，所以 Product backlog 就如同一個活的產出物。商業需求，市場狀況或技術的變化可能都會造成 Product backlog 的變動。
數個 Scrum Teams 通常會一起參與對同一個產品的開發。 一個 Product backlog 便被用於描述該產品即將進行的工作，並採用 Product Backlog 的某一種屬性來把這些事項分類。
Product backlog refinement，是向 Product backlog 中的事項添加詳細資訊，估算大小和排序的動作。這是一個持續的過程，由 Product Owner 和 Development Team 就 Product Backlog items 的細節進行協同合作。在 Product backlog 精煉的過程中，事項會被進行審查和修訂。Scrum Team 決定如何以及何時來完成精煉。精煉所花的時間通常不超過Development Team 百分之十的產能。 然而，Product Backlog items 可以隨時由Product Owner 或在 Product Owner 的斟酌下來做更新。
較高排序的 Product Backlog items 比起較低的 Product Backlog items，通常比較清楚，同時包含更多細節。因為比較明確以及更多細節，可以讓預估更精準；而排序較後的 Product Backlog items，細節會越少。Development team 會在下一個 Sprint 開發的 Product Backlog items 會先被精煉，使得這些事項都可以合理的在 Sprint 時間盒期限內「完成」。「備妥」的 Product Backlog 可以在 Sprint Planning 中被挑選出來，而能夠 Development Team 在下一個 Sprint 內「完成」。 Product Backlog items 的透明性通常要經過上述的精煉化活動來獲得。
Development Team 負責所有的估計。Product Owner 也許可以經由幫助 Development Team 了解以及選擇取捨來影響他們，然而還是要由實際做事的人來決定最終的預估。
監測達成目標的進度 在任何時候，用來達成目標的所有剩餘工作量都能夠被加總。Product Owner 至少在每次的 Sprint Reviews 中追蹤剩餘的工作量。Product Owner 將這次的剩餘工作量與之前做比較，進而評估預定的工作進度，是否能在期望時間內達成目標。這些資訊對所有的利害關係人都是透明公開的。
可以用各種不同關於趨勢走向的實務來預測進度，譬如：燃盡圖，燃起圖或累積流量圖。這些工具被證實是有用的，然而它們並不能用來取代經驗主義的重要性。在錯綜複雜的環境中，會發生什麼事是未知的。已經發生的事情，才能用來當做前瞻的決策的參考依據。
Sprint Backlog
Sprint Backlog 是一組在這次 Sprint 要執行的 Product Backlog items 加上如何交付產品Increment 和達到 Sprint 目標的計劃。 Sprint Backlog 是 Development Team 對下一個Increment 中所需要的功能以及將該功能轉換到「完成」Increment 所需工作的預測。
Sprint Backlog 讓 Development Team 識別出所有用來完成 Sprint 目標的必要工作。為了確保持續改善，它包含了至少一個在前次Sprint Retrospective 中優先級高的流程改進。 Sprint Backlog 是一個具有足夠細節的計劃，使得在 Daily Scrum 中可以了解正在發生的改變。 Development Team 在整個 Sprint 期間都會去修改 Sprint Backlog，使得 Sprint Backlog在 Sprint 期間裡慢慢變化而逐漸成形。 這樣的逐漸成形會隨著 Development Team 實作Sprint Backlog 的過程來發生，加上過程中學習而得到更多如何完成 Sprint 目標。
當需要有新的工作時，Development Team 便將其加到 Sprint Backlog 內。 隨著工作的進展或完成，團隊會去更新預估的剩餘工作量。當計劃內的某些部份被認定是不需要的，這些部分就會被移除。只有 Development Team 才能在 Sprint 期間內更改 Sprint Backlog。 Sprint Backlog 是 Development Team 在 Sprint 內計畫完成的工作，是一個可視性高且即時的工作畫面，且只屬於 Development Team 所擁有。
監督 Sprint 的進度
在 Sprint 的任何時間點都可以加總在 Sprint Backlog 內剩餘的總工作量。 Development Team 至少在 Daily Scrum 追蹤剩餘工作的總和，以預測達成本次 Sprint 目標的可能性。Development Team 可以藉由追蹤 Sprint 的剩餘工作來管理本身的進度。Increment Increment 是指在 Sprint 期間內完成的所有 Product Backlog items，以及所有先前 Sprint Increment 的價值總和。在 Sprint 的最後，新的 Increment 必須是「完成」的，這意味著它必須是可用的狀態，並符合 Scrum Team 對於「完成」之定義。在 Sprint 結束時，Increment 是一種可檢視，完成的工作實體，並可支持經驗主義。向願景或目標邁出更前進的一步。 無論 Product Owner 是否決定將其發佈，Increment 都必須是處於可用的狀態。
產出物透明性
Scrum 建立在透明性上，基於對產出物的理解做出把價值最佳化和控管風險的決策。在產出物完全透明的情況下，這些決定才會有可靠的基礎。 而當產出物沒有達到完全透明，可能會做出有瑕疵的決定，進而減低了價值，增加了風險。
Scrum Master 必須與 Product Owner，Development Team，和其它相關人員一起努力來了解產出物是否完全透明。當不是完全透明時 Scrum Master 必須幫助所有人應用最合適的作法。Scrum Master 可以透過檢視產出物，對模式的感知，仔細傾聽周圍發生的對話，以及檢視預期和實際結果之間的差異，來發現不完整的透明性。
Scrum Master 的工作是與 Scrum Team 和組織合作來提高產出物的透明性。 這項工作通常涉及學習，使人信服和改變。 透明性不會在一夜之間發生，然而它是一條道路。
「完成」之定義
當一個 Product Backlog item 或者 Increment 被描述為「完成」時，每個人都必須了解什麼是「完成」之定義。 雖然這會隨著 Scrum Team 的不同而有很大的差異，但成員們必須對什麼叫做工作完成有共識，如此才能確保透明性。 這就是 Scrum Team 對「完成」之定義，並且用它來評估產品 Increment 上的工作是否完成。
同樣的定義用來指導 Development Team，讓團隊知道在 Sprint Planning 中可以選擇多少 Product Backlog items。 每一個 Sprint 的目的是交付潛在可發佈的功能 Increment，而這些功能符合 Scrum Team 目前對「完成」之定義。
Development Team 在每個 Sprint 交付產品功能的 Increment。 這個 Increment 是可用的，因此 Product Owner 可以選擇立即發佈它。 如果「完成」之定義對 Increment 來說是開發組織的慣例，標準或指導方針的一部分，那麼所有的 Scrum Teams 都必須要遵守。
如果 Increment的「完成」不是開發組織的慣例，那麼 Development Team 就必須對這個產品訂下一個合適的「完成」之定義。如果有多個 Scrum Teams 在同一個系統或產品發佈上工作，那麼所有的 Development Team 就必須一起訂下一致的「完成」之定義。
每個 Increment 都是遞加於先前的 Increment，並經過徹底地測試以確保所有 Increment 都能一起運作。
隨著 Scrum Teams 的成熟，可以被預期的是，他們對「完成」之定義將擴大到包含更多更嚴謹的標準以達到更高的品質。當使用了新的定義，可能會發現一些之前已「完成」的Increment需要更多的工作。 任何一個產品或系統都應該有一個「完成」之定義，作為工作的標準。
結語
經由此指南提供 Scrum 知識，Scrum 同時也是免費的。Scrum 的角色，活動，產出物和規則都是不能改變的，雖然實施部分的 Scrum 是可能的，但結果並不是 Scrum。Scrum 只有在完整的時候才會存在，也才能有效的成為其他技巧，方法論，和實務發揮的運作舞臺。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。