Scrum是一個用于開發和維持復雜產品的框架，是一個增量的、迭代的開發過程。在這個框架中，整個開發過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的建議長度是2到4周(互聯網產品研發可以使用1周的Sprint)。在Scrum 中，使用產品 Backlog 來管理產品的需求，產品 Backlog 是一個按照商業價值排序的需求列表，列表條目的體現形式通常為用戶故事。Scrum 團隊總是先開發對客戶具有較高價值的需求。在 Sprint 中，Scrum 團隊從產品 Backlog 中挑選最高優先級的需求進行開發。挑選的需求在 Sprint 計劃會議上經過討論、分析和估算得到相應的任務列表，我們稱它為 Sprint backlog。在每個迭代結束時，Scrum 團隊將遞交潛在可交付的產品增量。 Scrum 起源于軟件開發項目，但它適用于任何復雜的或是創新性的項目。Scrum 的基本流程如圖 6-7 所示。

1．Scrum 的五個活動
Scrum 主要包括：產品待辦事項列表梳理、Sprint 計劃會議、每日 Scrum 會議、Sprint 評審會議、Sprint 回顧會議等五個活動。
（1）產品待辦事項列表梳理
產品待辦事項通常會很大，也很寬泛，而且想法會變來變去、優先級也會變化，所以產品待辦事項列表梳理是一個始終貫穿整個 Scrum 項目的活動。該活動包含但不限于以下的內容：保持產品待辦事項列表有序、把看起來不再重要的事項移除或者降級、增加或提升涌現出來的或變得更重要的事項、將事項分解成更小的事項、將事項歸并為更大的事項、對事項進行估算。
產品待辦事項列表梳理的一個最大好處是為即將到來的幾個 Sprint 做準備。為此，梳理時會特別關注那些即將被實現的事項。需要考慮不少因素，這包括但不限于以下的內容：
理想情況下，下一個 Sprint 的備選事項都應該提升“商業價值”。開發團隊需要能夠在一個 Sprint 內完成每一個事項。每個人都需要清楚預期產出是什么。
產品開發決定了，有可能需要其他的技能和輸入。因此，產品待辦事項列表梳理最好是所有團隊成員都參與的活動，而不單單是產品負責人。
（2）Sprint 計劃會議
每個 Sprint 都以 Sprint 計劃會議作為開始，這是一個固定時長的會議，在這個會議中，Scrum 團隊共同選擇和理解在即將到來的 Sprint 中要完成的工作。
整個團隊都要參加 Sprint 計劃會議。針對排好序的產品待辦事項列表（Product Backlog），產品負責人和開發團隊成員討論每個事項，并對該事項達成共識，包括根據當前的“完成的定義”，為了完成該事項所需要完成的所有事情。所有的 Scrum 會議都是限定時長的。Sprint 計劃會議推薦時長是 Sprint 中的每周對應兩小時或者更少（例如，一個 Sprint 包含 2 個星期，則 Sprint 計劃會議時長應為 4 個小時或者更少）。因為會議是限制時長的,Sprint 計劃會議的成功十分依賴于產品待辦事項列表的質量。這就是產品待辦事項列表梳理十分重要的原因。
在 Scrum 中，Sprint 計劃會議有兩部分：
決定在 Sprint 中需要完成哪些工作
決定這些工作如何完成
第一部分：需要完成哪些工作?
在會議的第一部分，產品負責人向開發團隊介紹排好序的產品待辦事項，整個Scrum團隊共同理解這些工作。
Sprint 中需要完成的產品待辦事項數目完全由開發團隊決定。為了決定做多少，開發團隊需要考慮當前產品增量的狀態，團隊過去的工作情況，團隊當前的生產能力，以及排好序的產品待辦事項列表。做多少工作只能由開發團隊決定。產品負責人或任何其他人，都不能給開發團隊強加更多的工作量。
通常 Sprint 都有個目標，稱作 Sprint 目標。這將十分有效地幫助大家更加專注于需要完成的工作的本質，而不必花太多精力去關注那些對于我們需要完成的工作并不重要的小細節。
第二部分：如何完成工作？
在會議的第二部分里，開發團隊需要根據當前的“完成的定義”一起決定如何實現下一個產品增量。他們進行足夠的設計和計劃，從而有信心可以在 Sprint 中完成所有工作。前幾天的工作會被分解成小的單元，每個工作單元不超過一天。之后要完成的工作可以稍大些，以后再對它們進行分解。
決定如何完成工作是開發團隊的職責，決定做什么則是產品負責人的職責。在計劃會議的第二部分，產品負責人可以繼續留下來回答問題，以及澄清一些誤解。
不管怎樣，團隊應該很容易找到產品負責人。
Sprint 計劃會議的產出。Sprint計劃會議最終需要 Scrum 團隊對 Sprint 需要完成工作的數量和復雜度達成共識，并預期在一個合理的條件范圍內完成它們。開發團隊預測并共同承諾他們要完成的工作量。總而言之：在 Sprint 計劃會議中，開發團隊和產品負責人一起考慮并討論產品待辦事項，確保他們對這些事項的理解，選擇一些他們預測能完成的事項，創建足夠詳細的計劃來確保他們能夠完成這些事項。
最終產生的待辦事項列表就是“Sprint 待辦事項列表（Sprint Backlog）”。
（3）每日 Scrum 會議
開發團隊是自組織的。開發團隊通過每日 Scrum 會議來確認他們仍然可以實現 Sprint 的目標。這個會議每天在同樣的時間和同樣的地點召開。每一個開發團隊成員需要提供以下三點信息：
從上一個每日 Scrum 到現在，我完成了什么；從現在到下一個每日 Scrum，我計劃完成什么；有什么阻礙了我的進展。
每日 Scrum 中可能有簡要的問題澄清和回答，但是不應該有任何話題的討論。通常，許多團隊會在每日 Scrum 之后馬上開會處理他們遇到的任何問題。
每日 Scrum 既不是向管理層匯報，也不是向產品負責人或者 ScrumMaster 匯報。它是一個開發團隊內部的溝通會議，來保證他們對現狀有一致的了解。只有 Scrum 團隊的成員，包括 ScrumMaster 和產品負責人，可以在會議中發言。其他感興趣的人可以來旁聽。在必要時，開發團隊會基于會議中的發現重新組織他們的工作來完成 Sprint 的目標。
每日 Scrum 是 Scrum 的一個關鍵組成部分，它可以帶來透明性,信任和更好的績效。它能幫助快速發現問題，并促進團隊的自組織和自立。所有 Scrum 會議都是限定時長的。每日 Scrum 通常不超過 15 分鐘。
（4）Sprint 評審會議
Sprint 結束時，Scrum 團隊和相關人員一起評審 Sprint 的產出。Sprint 評審會議的推薦時長是 Sprint 中的每一周對應一個小時（例如，一個 Sprint 包含 2 個星期，則 Sprint 評審會議時長為 2 個小時）。
討論圍繞著 Sprint 中完成的產品增量。由于 Sprint 的產出會涉及一些人的“利益”，因此一個明智的做法是邀請他們參加這個會議，這會很有幫助。這個會議是個非正式的會議,幫助大家了解我們目前進展到哪里，并一起討論我們下一步如何推進。每個人都可以在 Sprint 評審會議上發表意見。當然，產品負責人會對未來做出最終的決定，并適當地調整產品待辦事項列表 Product Backlog。
團隊會找到他們自己的方式來開 Sprint 評審會議。通常會演示產品增量,整個小組也會經常討論他們在 Sprint 中觀察到了什么、有哪些新的產品想法出現。他們還會討論產品待辦事項列表的狀態、可能的完成日期以及在這些日期前能完成什么。
Sprint 評審會議向每個人展示了當前產品增量的概況。因此，通常都會在 Sprint 評審會議中調整產品待辦事項列表。
（5）Sprint 回顧會議
在每個 Sprint 結束后,Scrum 團隊會聚在一起開 Sprint 回顧會議,目的是回顧一下團隊在流程人際關系以及工具方面做得如何。團隊識別出哪些做得好,哪些做得不好,并找出潛在的改進事項,為將來的改進制定計劃。Sprint 回顧會議的推薦時長是 Sprint 中的每一周對應一個小時（例如，一個 Sprint 包含 2 個星期，則 Sprint 回顧會議時長為 2 個小時）。
Scrum 團隊總是在 Scrum 的框架內，改進他們自己的流程。
2．Scrum 的 5 大價值觀
Scrum 的 5 大價值觀為：
承諾—愿意對目標做出承諾。
專注—把你的心思和能力都用到你承諾的工作上去。
開放—Scrum 把項目中的一切開放給每個人看。
尊重—每個人都有他獨特的背景和經驗。
勇氣—有勇氣做出承諾，履行承諾，接受別人的尊重。