Scrum 指南的目的
我們在 1990 年代初期開發了 Scrum。我們在 2010 年編寫了第一版 Scrum 指南，以幫助全世界的人們了解 Scrum。從那時起，我們通過小的、功能性的更新改進了指南。我們一起支持它。
Scrum 指南包含 Scrum 的定義。框架的每個元素都有一個特定的目的，這對於使用 Scrum 實現的整體價值和結果至關重要。改變 Scrum 的核心設計或思想、遺漏元素或不遵循 Scrum 規則，會掩蓋問題並限制 Scrum 的好處，甚至可能使其變得無用。
我們關注在不斷增長的復雜世界中越來越多地使用 Scrum。我們很慚愧地看到 Scrum 被許多領域采用，這些領域具有本質上復雜的工作，超出了 Scrum 發源地的軟件產品開發。隨着 Scrum 的廣泛使用，開發人員、研究人員、分析師、科學家和其他專家開始工作。我們在 Scrum 中使用“開發人員”這個詞不是為了排除，而是為了簡化。如果您從 Scrum 中獲得價值，請考慮將自己包括在內。
在使用 Scrum 時，可以找到、應用和設計適合本文檔中描述的 Scrum 框架的模式、流程和見解。它們的描述超出了 Scrum 指南的目的，因為它們是上下文敏感的，並且在 Scrum 使用之間存在很大差異。在 Scrum 框架內使用的此類策略差異很大，並在別處進行了描述。
Purpose of the Scrum Guide
We developed Scrum in the early 1990s. We wrote the first version of the Scrum Guide in 2010 to help people worldwide understand Scrum. We have evolved the Guide since then through small, functional updates. Together, we stand behind it.
The Scrum Guide contains the definition of Scrum. Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.
We follow the growing use of Scrum within an ever-growing complex world. We are humbled to see Scrum being adopted in many domains holding essentially complex work, beyond software product development where Scrum has its roots. As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work. We use the word “developers” in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included.
As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere.
Scrum 定義
Scrum 是一個輕量級框架，可幫助人員、團隊和組織通過針對復雜問題的自適應解決方案創造價值。
簡而言之，Scrum 需要一個 Scrum Master 來營造這樣一個環境：
Scrum 很簡單。按原樣嘗試並確定其哲學、理論和結構是否有助於實現目標和創造價值。Scrum 框架故意不完整，只定義了實現 Scrum 理論所需的部分。Scrum 建立在使用它的人們的集體智慧之上。Scrum 規則不是為人們提供詳細的說明，而是指導他們的關系和互動。
可以在該框架內采用各種過程、技術和方法。Scrum 環繞現有實踐或使其變得不必要。Scrum 使當前管理、環境和工作技術的相對效率可見，以便進行改進。
Scrum Definition
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
- A Product Owner orders the work for a complex problem into a Product Backlog.
- The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
- The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
- Repeat
Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.
Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.
Scrum 理論
Scrum 建立在經驗主義和精益思想之上。經驗主義斷言，知識來自經驗，並根據觀察到的東西做出決定。精益思想減少浪費並專注於基本要素。
Scrum 采用迭代的、增量的方法來優化可預測性和控制風險。Scrum 讓一群人共同擁有完成工作的所有技能和專業知識，並根據需要分享或獲得這些技能。
Scrum 結合了四個正式事件，以便在一個包含事件（Sprint）中進行檢查和調整。這些事件之所以有效，是因為它們實現了透明、檢查和適應的經驗 Scrum 支柱。
Scrum Theory
Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.
Scrum employs an iterative, incremental approach to optimize predictability and to control risk. Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed.
Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation.
透明度
緊急過程和工作必須對執行工作的人和接受工作的人可見。使用 Scrum，重要的決策是基於其三個正式工件的感知狀態。透明度低的工件可能會導致做出降低價值和增加風險的決策。
透明度使檢查成為可能。不透明的檢查是誤導和浪費的。
Transparency
The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts. Artifacts that have low transparency can lead to decisions that diminish value and increase risk.
Transparency enables inspection. Inspection without transparency is misleading and wasteful.
檢查
Scrum 工件和達成一致目標的進度必須經常和勤奮地檢查，以發現潛在的不受歡迎的差異或問題。為了幫助檢查，Scrum 以五個事件的形式提供了節奏。
檢查使適應成為可能。沒有適應的檢查被認為是沒有意義的。Scrum 事件旨在激發變革。
Inspection
The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of its five events.
Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.
適應
如果過程的任何方面超出可接受的范圍，或者如果產生的產品不可接受，則必須調整正在應用的過程或正在生產的材料。必須盡快進行調整，以盡量減少進一步的偏差。
當相關人員沒有被授權或自我管理時，適應變得更加困難。Scrum 團隊應該在通過檢查學習任何新事物的那一刻進行調整。
Adaption
If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.
Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.
Scrum 價值觀
Scrum 的成功使用取決於人們更加精通以下五個價值觀：
承諾、專注、開放、尊重和勇氣
Scrum 團隊致力於實現其目標並相互支持。他們的主要重點是 Sprint 的工作，以盡可能實現這些目標。Scrum 團隊及其利益相關者對工作和挑戰持開放態度。Scrum 團隊成員相互尊重，成為有能力、獨立的人，並受到與他們一起工作的人的尊重。Scrum 團隊成員有勇氣做正確的事情，解決棘手的問題。
這些價值觀為 Scrum 團隊的工作、行動和行為指明了方向。做出的決定、采取的步驟和使用 Scrum 的方式應該加強這些價值觀，而不是削弱或削弱它們。Scrum 團隊成員在處理 Scrum 事件和工件時學習和探索價值。當這些價值觀被 Scrum 團隊和與他們一起工作的人體現時，透明度、檢查和適應的經驗性 Scrum 支柱就會建立信任。
Scrum Values
Successful use of Scrum depends on people becoming more proficient in living five values:
Commitment, Focus, Openness, Respect, and Courage
The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems.
These values give direction to the Scrum Team with regard to their work, actions, and behavior. The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them. The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts. When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.
Scrum 團隊
Scrum 的基本單位是一個小團隊，一個 Scrum 團隊。Scrum 團隊由一名 Scrum Master、一名產品負責人和開發人員組成。在 Scrum 團隊中，沒有子團隊或層次結構。它是一個由專業人士組成的有凝聚力的單位，一次專注於一個目標，即產品目標。
Scrum 團隊是跨職能的，這意味着成員擁有在每個 Sprint 中創造價值所需的所有技能。他們也是自我管理的，這意味着他們在內部決定誰做什么、什么時候做什么以及如何做。
Scrum 團隊負責所有與產品相關的活動，包括利益相關者協作、驗證、維護、運營、實驗、研究和開發，以及任何其他可能需要的活動。他們由組織構建並授權來管理自己的工作。以可持續的速度在 Sprint 中工作可以提高 Scrum 團隊的注意力和一致性。
整個 Scrum 團隊負責在每個 Sprint 中創建有價值的、有用的增量。Scrum 在 Scrum 團隊中定義了三個特定的職責：開發人員、產品負責人和 Scrum Master
Scrum Team
The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.
團隊規模
Scrum 團隊小到可以保持敏捷，大到可以在 Sprint 中完成重要工作，通常是 10 人或更少。總的來說，我們發現較小的團隊溝通更好，效率更高。
Team Size
The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive.
多個團隊
如果 Scrum 團隊變得太大，他們應該考慮重組為多個有凝聚力的 Scrum 團隊，每個團隊都專注於相同的產品。因此，他們應該共享相同的產品目標、產品待辦列表和產品負責人。
[…]
如果有多個 Scrum 團隊一起開發一個產品，他們必須相互定義並遵守相同的完成定義。
Multiple teams
If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.
If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.
開發人員
開發人員是 Scrum 團隊中致力於在每個 Sprint 中創建可用增量的任何方面的人員。
開發人員所需的特定技能通常很廣泛，並且會因工作領域而異。但是，開發人員始終負責：
為 Sprint 制定計划，即 Sprint Backlog；
通過堅持完成的定義來灌輸質量；
每天根據 Sprint 目標調整他們的計划；和，
作為專業人士相互問責。
Developers
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:
- Creating a plan for the Sprint, the Sprint Backlog;
- Instilling quality by adhering to a Definition of Done;
- Adapting their plan each day toward the Sprint Goal; and,
- Holding each other accountable as professionals.
產品擁有者
產品負責人負責最大化由 Scrum 團隊工作產生的產品價值。如何做到這一點可能因組織、Scrum 團隊和個人而異。
產品負責人還負責有效的產品待辦列表管理，其中包括：
- 制定並明確傳達產品目標；
- 創建並清楚地傳達產品待辦事項列表項；
- 訂購產品待辦列表項；和，
- 確保產品待辦列表透明、可見和理解。
- 產品負責人可以完成上述工作，也可以將責任委托給其他人。無論如何，產品負責人仍然負責。
- 產品負責人要取得成功，整個組織都必須尊重他們的決定。這些決定在產品待辦列表的內容和順序中是可見的，並且通過 Sprint 評審中的可檢查增量可見。
- 產品負責人是一個人，而不是一個委員會。產品負責人可能代表產品待辦列表中許多利益相關者的需求。那些想要更改產品待辦列表的人可以通過嘗試說服產品負責人來實現。
Product Owner
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is also accountable for effective Product Backlog management, which includes:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and,
- Ensuring that the Product Backlog is transparent, visible and understood.
- The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
- For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.
- The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.
Scrum Master
Scrum Master 負責建立 Scrum 指南中定義的 Scrum。他們通過幫助 Scrum 團隊和組織內的每個人了解 Scrum 理論和實踐來做到這一點。
Scrum Master 對 Scrum 團隊的有效性負責。他們通過讓 Scrum 團隊在 Scrum 框架內改進其實踐來做到這一點。
Scrum Master 是真正的領導者，為 Scrum 團隊和更大的組織服務。
Scrum Master
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
Scrum Masters are true leaders who serve the Scrum Team and the larger organization.
為團隊服務
Scrum Master 以多種方式為 Scrum 團隊服務，包括：
- 指導團隊成員進行自我管理和跨職能；
- 幫助 Scrum 團隊專注於創造滿足完成定義的高價值增量；
- 消除阻礙 Scrum 團隊進展的障礙；和，
- 確保所有 Scrum 事件發生並且是積極的、富有成效的，並保持在時間范圍內。
Service to the Team
- The Scrum Master serves the Scrum Team in several ways, including:
- Coaching the team members in self-management and cross-functionality;
- Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
- Causing the removal of impediments to the Scrum Team’s progress; and,
- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
為產品負責人服務
Scrum Master 以多種方式為組織服務，包括：
- 領導、培訓和指導組織采用 Scrum；
- 計划和建議組織內的 Scrum 實施；
- 幫助員工和利益相關者理解和制定復雜工作的經驗方法；和，
- 消除利益相關者和 Scrum 團隊之間的障礙。
Service to the Product Owner
The Scrum Master serves the Product Owner in several ways, including:
- Helping find techniques for effective Product Goal definition and Product Backlog management;
- Helping the Scrum Team understand the need for clear and concise Product Backlog items;
- Helping establish empirical product planning for a complex environment; and,
- Facilitating stakeholder collaboration as requested or needed.
為本組織服務
Scrum Master 以多種方式為組織服務，包括：
- 領導、培訓和指導組織采用 Scrum；
- 計划和建議組織內的 Scrum 實施；
- 幫助員工和利益相關者理解和制定復雜工作的經驗方法；和，
- 消除利益相關者和 Scrum 團隊之間的障礙。
Service to the Organization
The Scrum Master serves the organization in several ways, including:
- Leading, training, and coaching the organization in its Scrum adoption;
- Planning and advising Scrum implementations within the organization;
- Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
- Removing barriers between stakeholders and Scrum Teams.
Scrum 事件
Sprint 是所有其他事件的容器。Scrum 中的每個事件都是檢查和調整 Scrum 工件的正式機會。這些事件專門設計用於實現所需的透明度。未能按規定操作任何事件會導致失去檢查和適應的機會。在 Scrum 中使用事件來創建規律性並最小化 Scrum 中未定義的會議的需求。
最理想的是，所有活動都在同一時間和地點舉行，以降低復雜性。
Scrum Events
The Sprint is a container for all other events. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required. Failure to operate any events as prescribed results in lost opportunities to inspect and adapt. Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.
Optimally, all events are held at the same time and place to reduce complexity.
沖刺 (Sprint)
Sprint 是 Scrum 的心跳，在這里將想法轉化為價值。
它們是一個月或更短的固定長度事件，以創建一致性。新的 Sprint 在上一個 Sprint 結束后立即開始。
實現產品目標所需的所有工作，包括 Sprint 計划、每日 Scrums、Sprint 審查和 Sprint 回顧，都在 Sprint 中進行。
在 Sprint 期間：
- 沒有進行會危及 Sprint 目標的更改；
- 質量不下降；
- 產品待辦列表根據需要進行細化；和，
- 隨着了解的更多，范圍可能會被澄清並與產品負責人重新協商。
- 沖刺通過確保至少每個日歷月檢查和調整產品目標的進度來實現可預測性。當 Sprint 的期限太長時，Sprint 目標可能會失效，復雜性可能會增加，風險可能會增加。可以采用更短的 Sprint 來產生更多的學習周期，並將成本和努力的風險限制在更短的時間范圍內。每個 Sprint 都可以被視為一個短期項目。
- 存在各種用於預測進度的實踐，例如燃盡、燃盡或累積流量。雖然被證明是有用的，但這些並不能取代經驗主義的重要性。在復雜的環境中，會發生什么是未知的。只有已經發生的事情才能用於前瞻性決策。
The Sprint
Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.
All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.
- During the Sprint:
- No changes are made that would endanger the Sprint Goal;
- Quality does not decrease;
- The Product Backlog is refined as needed; and,
- Scope may be clarified and renegotiated with the Product Owner as more is learned.
Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project.
Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.
沖刺取消
如果 Sprint 目標過時，則 Sprint 可能會被取消。只有產品負責人有權取消 Sprint。
Sprint Cancellation
A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.
沖刺計划
Sprint 計划通過布置要為 Sprint 執行的工作來啟動 Sprint。這個最終計划是由整個 Scrum 團隊的協作工作創建的。
產品負責人確保與會者准備好討論最重要的產品待辦事項列表項目以及它們如何映射到產品目標。Scrum 團隊還可以邀請其他人參加 Sprint 計划以提供建議。
Sprint 計划涉及以下主題：
主題一：為什么這個 Sprint 有價值？
產品負責人提議產品如何在當前 Sprint 中增加其價值和效用。然后，整個 Scrum 團隊協作定義一個 Sprint 目標，以傳達為什么 Sprint 對利益相關者有價值。Sprint 目標必須在 Sprint 計划結束之前完成。
主題二：這個 Sprint 可以做什么？
通過與產品負責人的討論，開發人員從產品待辦列表中選擇要包含在當前 Sprint 中的項目。Scrum 團隊可能會在此過程中細化這些項目，從而增加理解和信心。
選擇在 Sprint 中可以完成多少可能具有挑戰性。然而，開發人員對他們過去的表現、即將到來的容量以及他們的完成定義了解得越多，他們對 Sprint 的預測就越有信心。
主題三：選擇的工作將如何完成？
對於每個選定的產品待辦列表項，開發人員計划創建滿足完成定義的增量所需的工作。這通常是通過將產品待辦列表項分解為一天或更短的更小的工作項來完成的。如何做到這一點由開發人員自行決定。沒有人告訴他們如何將產品待辦列表項轉化為價值增量。
Sprint 目標、為 Sprint 選擇的產品待辦列表項以及交付它們的計划統稱為 Sprint 待辦列表。
Sprint 計划的時間限制為一個月的 Sprint 最多 8 小時。對於較短的 Sprint，事件通常較短。
Sprint Planning
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.
Sprint Planning addresses the following topics:
Topic One: Why is this Sprint valuable? The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.
Topic Two: What can be Done this Sprint? Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.
Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
Topic Three: How will the chosen work get done? For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.
The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.
Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
每日站會
Daily Scrum 的目的是檢查實現 Sprint 目標的進度並根據需要調整 Sprint Backlog，調整即將到來的計划工作。
每日 Scrum 是 Scrum 團隊開發人員的 15 分鍾活動。為了降低復雜性，它在 Sprint 的每個工作日在同一時間和地點舉行。如果產品負責人或 Scrum Master 正在積極處理 Sprint 待辦列表中的項目，他們作為開發人員參與。
開發人員可以選擇他們想要的任何結構和技術，只要他們的 Daily Scrum 專注於實現 Sprint 目標的進展並為第二天的工作制定可操作的計划。這創造了焦點並改善了自我管理。
每日 Scrums 改善溝通，識別障礙，促進快速決策，從而消除其他會議的需要。
Daily Scrum 並不是唯一一次允許開發人員調整他們的計划。他們經常全天開會，就調整或重新規划 Sprint 的其余工作進行更詳細的討論。
Daily Scrum
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.
Sprint Review
Sprint Review 的目的是檢查 Sprint 的結果並確定未來的調整。Scrum 團隊向主要利益相關者展示他們的工作結果，並討論實現產品目標的進展。
在活動期間，Scrum 團隊和利益相關者審查在 Sprint 中完成的內容以及他們的環境中發生了什么變化。根據這些信息，與會者就下一步做什么進行協作。產品待辦列表也可能會進行調整以迎接新的機會。Sprint Review 是一個工作會議，Scrum 團隊應避免將其限制為演示。
Sprint Review 是 Sprint 的倒數第二個事件，並且在為期一個月的 Sprint 中將時間限制為最多四個小時。對於較短的 Sprint，事件通常較短。
Sprint Review
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
沖刺回顧
Sprint 回顧的目的是計划提高質量和有效性的方法。
Scrum 團隊檢查上一個 Sprint 在個人、交互、流程、工具及其完成定義方面的進展情況。檢查的元素通常隨着工作領域的不同而變化。確定了導致他們誤入歧途的假設並探索了它們的起源。Scrum 團隊討論了 Sprint 中哪些方面做得好，遇到了哪些問題，以及這些問題是如何（或沒有）解決的。
Scrum 團隊確定最有幫助的更改以提高其有效性。盡快解決最具影響力的改進。它們甚至可能被添加到下一個 Sprint 的 Sprint Backlog 中。
Sprint 回顧會結束 Sprint。對於一個月的 Sprint，時間限制為最多三個小時。對於較短的 Sprint，事件通常較短。
Sprint Retrospective
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Scrum 工件
Scrum 的工件代表工作或價值。它們旨在最大限度地提高關鍵信息的透明度。因此，每個檢查它們的人都有相同的適應基礎。
每個工件都包含一個承諾，以確保它提供的信息可以提高透明度和重點，可以衡量進度：
- 對於產品待辦列表，它是產品目標。
- 對於 Sprint Backlog，它是 Sprint 目標。
- 對於增量，它是完成的定義。
這些承諾的存在是為了加強 Scrum 團隊及其利益相關者的經驗主義和 Scrum 價值觀。
Scrum Artifacts
Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.
Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
- For the Product Backlog it is the Product Goal.
- For the Sprint Backlog it is the Sprint Goal.
- For the Increment it is the Definition of Done.
These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.
產品積壓
產品待辦列表是一個緊急的、有序的清單，列出了改進產品所需的內容。它是 Scrum 團隊承擔的工作的唯一來源。
可以由 Scrum 團隊在一個 Sprint 內完成的產品待辦事項列表項目被視為已准備好在 Sprint 計划活動中進行選擇。他們通常在提煉活動后獲得這種程度的透明度。產品待辦列表細化是將產品待辦列表項分解並進一步定義為更小更精確的項的行為。這是添加詳細信息（例如描述、訂單和尺寸）的持續活動。屬性通常因工作領域而異。
將進行工作的開發人員負責調整大小。產品負責人可以通過幫助開發人員理解和選擇權衡來影響他們。
Product Backlog
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.
產品目標
產品待辦事項承諾：產品目標
產品目標描述了產品的未來狀態，可以作為 Scrum 團隊計划的目標。產品目標在產品待辦列表中。產品待辦列表的其余部分出現以定義“什么”將實現產品目標。
產品是傳遞價值的載體。它有明確的邊界、已知的利益相關者、明確定義的用戶或客戶。產品可以是服務、實物產品或更抽象的東西。
產品目標是 Scrum 團隊的長期目標。他們必須先完成（或放棄）一個目標，然后才能開始下一個目標。
Product Goal
Product backlog Commitment: Product Goal
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.
沖刺積壓
因此，隨着學到的更多，Sprint Backlog 在整個 Sprint 中都會更新。它應該有足夠的細節，以便他們可以在 Daily Scrum 中檢查他們的進度。
Sprint Backlog
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.
沖刺目標
Sprint backlog 承諾：Sprint 目標
Sprint 目標是 Sprint 的唯一目標。盡管 Sprint 目標是開發人員的承諾，但它在實現它所需的確切工作方面提供了靈活性。Sprint 目標還創造了一致性和重點，鼓勵 Scrum 團隊一起工作而不是單獨的計划。
Sprint 目標是在 Sprint 計划活動期間創建的，然后添加到 Sprint 待辦事項列表中。當開發人員在 Sprint 期間工作時，他們牢記 Sprint 目標。如果工作結果與他們預期的不同，他們會與產品負責人合作，在不影響 Sprint 目標的情況下協商 Sprint 中 Sprint Backlog 的范圍。
Sprint Progress
Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.
沖刺目標
Sprint backlog 承諾：Sprint 目標
Sprint 目標是 Sprint 的唯一目標。盡管 Sprint 目標是開發人員的承諾，但它在實現它所需的確切工作方面提供了靈活性。Sprint 目標還創造了一致性和重點，鼓勵 Scrum 團隊一起工作而不是單獨的計划。
Sprint 目標是在 Sprint 計划活動期間創建的，然后添加到 Sprint 待辦事項列表中。當開發人員在 Sprint 期間工作時，他們牢記 Sprint 目標。如果工作結果與他們預期的不同，他們會與產品負責人合作，在不影響 Sprint 目標的情況下協商 Sprint 中 Sprint Backlog 的范圍。
Sprint Goal
Sprint backlog Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.
增量
增量是實現產品目標的具體墊腳石。每個增量都是所有先前增量的相加並經過徹底驗證，確保所有增量協同工作。為了提供價值，增量必須是可用的。
可以在一個 Sprint 中創建多個增量。增量的總和在 Sprint Review 中呈現，從而支持經驗主義。但是，增量可能會在 Sprint 結束之前交付給利益相關者。Sprint Review 永遠不應被視為釋放價值的大門。
工作不能被視為增量的一部分，除非它符合完成的定義。
Increment
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
Work cannot be considered part of an Increment unless it meets the Definition of Done.
完成的定義
增量承諾：完成的定義
完成的定義是當增量滿足產品要求的質量措施時對增量狀態的正式描述。
產品待辦列表項滿足完成定義的那一刻，增量就誕生了。
完成的定義通過為每個人提供對作為增量的一部分完成的工作的共同理解來創建透明度。如果一個產品待辦列表項不符合完成的定義，它就不能發布，甚至不能在 Sprint 評審中展示。相反，它返回到產品待辦列表以供將來考慮。
如果增量的完成定義是組織標准的一部分，則所有 Scrum 團隊必須至少遵循它。如果它不是組織標准，Scrum 團隊必須創建適合產品的完成定義。
開發人員必須符合完成的定義。如果有多個 Scrum 團隊一起開發一個產品，他們必須相互定義並遵守相同的完成定義。
Definition of Done
Increment Commitment: Definition of Done
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.
尾注
Scrum 是免費的，並在本指南中提供。如本文所述，Scrum 框架是不可變的。雖然只實施部分 Scrum 是可能的，但結果不是 Scrum。Scrum 僅作為整體存在，並且作為其他技術、方法和實踐的容器發揮作用。
End Note The Scrum
Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
- How to Prioritize Product Backlog Using MoSCoW Method
- How to Prioritize Product Backlog Using 100 Points Methods?
- What is Burndown Chart in Scrum?
- What is the Role-Feature-Reason Template?
- Write SMART Goals & INVEST for User Stories
- What is Agile Estimation?
- What is Story Point in Agile? How to Estimate a User Story?
- User Story Splitting - Vertical Slice vs Horizontal Slice
- Effective User Stories - 3C's and INVEST Guide