1.1 ScurmMaster
作為Scrum流程的捍衛者和佈道者，ScrumMaster在Scrum團隊中起到至關重要的作用，他們確保團隊使用正確的流程，確保團隊正確地召開各種會議，他們訓練團隊的敏捷思維，他們和團隊外的相關干係人溝通。根據最新的Scrum研究報告，ScrumMaster自組織中傾向於服務於多個Scrum團隊。另一個傾向就是在組織中ScrumMaster同專案經理分擔職責。
ScrumMaster對Scrum團隊而言，是一位服務型領導。ScrumMaster幫助Scrum團隊之外的人瞭解他如何與Scrum團隊互動是有益的，通過改變他們與Scrum團隊的協作的互動方式來最大化Scrum團隊所創造的價值。
--服務於產品負責人 --服務於開發團隊 --服務於組織
ScrumMaster的職業發展路線通常有如下4個方向
(1) 服務於更多個團隊或者更具挑戰性的問題
作為ScrumMaster,最開始一般都是從服務於一個團隊開始。在經歷過一段時間的磨合以後，團隊的成熟度越來越高，越來越穩定。ScrumMaster就可以去尋找更多的挑戰了
(2)成為Agile Coach
有些ScrumMaster在經歷過一段時間的工作以後，他們發現自己熱衷於激發團隊進行創造的過程，並且無所謂產品本身。在經歷了一段時間的經驗積累以後，他們非常希望可以把這些經驗分享給其他新手ScrumMaster，對於這種人來說，轉型成為Agile Coach就是一個非常不錯的選擇。
如果我們把Agile Coach的成長之路分成三個逐步躍升的層級。那麼第一個需要達到的入門層級就是作為敏捷團隊的協調者（在團隊中角色叫做ScrumMaster），在這個級別需要實踐者具備敏捷實踐和協調的能力。接下來第二層就是Agile Coach了，與之前的一個級別的區別是，Agile Coach具有更多的實踐知識足以支撐他們解決更復雜的問題的同時，還具備引導，教導和專業指導的技能。在這條職業發展的路徑的頂峰是企業級Agile Coach，根據每個人背景 的不同他們可能會有各自非常擅長的領域，分別是技術領域（開發出身），商務領域（產品負責人出身）和變革領域（ScrumMaster）出身。但是，坦白的來講，在目前的形勢下能夠做到企業級Agile Coach的人還是很少的。因為這些人的級別和能力和公司的CEO是在同一水平的，大部分具有這樣能力的人都直接會選擇做CEO.
(3)成為產品負責人
還有一些人，也許做了一段時間ScrumMaster以後，發現自己對構建產品的過程很感興趣，那麼成為一個產品負責人就是他們的最佳選擇。當然，我並不是說產品負責人在組織中高於ScrumMaster這個角色。在理論上，這兩個角色是平級的關係。
(4)成為管理者
對於像你這種從傳統的專案經理轉型成為ScrumMaster的人來說，也許做了一段時間的ScrumMaster以後，你仍舊更希望轉回到傳統的管理角色上來。如果這時候，組織裡有機會，那麼也是可以成為管理者的。
ScrumMaster每日工作列表
一天的開始
1.更新和檢查目前衝刺的燃盡圖報表。 2.如果團隊落後於時間表，ScrumMaster需要幫助團隊想辦法追上進度。同時，ScrumMaster需要確保所有完成的任務都已經被標記成了完成，這樣燃盡圖的資料才準確。 3.檢查Sprint待辦列表裡的條目和相應的任務情況。
3.1 檢查是否有任何遺漏資訊
- 遺漏條目的工作量估算資訊。
- 遺漏具體任務的估算資訊。
- 正在進行和已經完成的任務遺漏任務人資訊。
3.2 檢查是否有任何不一致的資訊
- 是否有已經決定了不做了的條目仍舊可以被選中。
- 已經完成了的任務卻沒有標記成完成。
- 沒有完成的任務卻標記成完成。
ScrumMaster需要追蹤這些問題，並提醒相應的團隊成員作出更正。
工作期間
1.找出所有影響進度的工作 2.如果需要的話，協助團隊解決這些問題。 - 保護團隊成員不被團隊外的其他人打擾。 - 教育團隊成員：他們應該先嚐試自己解決問題，如果解決不了的話他們需要找ScrumMaster來解決問題。 3.協調Scrum每日戰會 - 展示燃盡圖 - 聽取團隊成員關於每日站會的三個問題的回答。 - 明確下一步行動計劃和責任人。 - 和團隊分享有用的資訊。 4.評審新加入產品列表的使用者故事，技術故事和問題，確保新加入的條目可以被正確地指派到相應Scrum團隊。
每日工作結束
和每天開始時一樣： 評審狀態，檢視是否有任何遺漏，錯誤的資訊，跟蹤記錄團隊待解決問題的狀態。
準備計劃會議
1.協調產品列表梳理會議。 2.統計下一個的迭代的生產能力。 - 統計團隊成員下一個Sprint的休假計劃，公共假期和其他影響生產力的資訊。 - 估算團隊下個迭代的生產力。 3.在各種電子和物理工具上更新相應的資訊。
計劃會議時
1.從頭到尾產看產品列表裡的條目，並且將條目一個一個地從優先順序最高的開始順序念給團隊。 2.協調估算過程。 3.記錄團隊討論的內容（例如，估算的工作量，條目的詳情）。 4.將相應的條目拖拽到下一個Sprint的代辦列表。 5.建議團隊在工作量範圍以外多評估一部分使用者故事以備不時之需。
在評審會議上
ScrumMaster需要組織會議確保相應成員到場。
在回顧會議上
1.ScrumMaster組織團隊成員一起回顧自上一個回顧會議以後團隊的工作狀態。 2.ScrumMaster組織，收集和記錄團隊成員討論的資訊。 3.ScrumMaster協調確認下一個迭代團隊需要做的改進措施以及負責人。
ScrumMaster小結：
對於傳統的專案經理來說，他對專案負最終的責任，因此他也就同時被賦予了領導專案成員的權利。在專案當中，無論是開發，測試還是產品經理，他們都是專案經理的下級，專案經理給他們分配任務，他們有義務按照專案經理的命令來完成任務。但是在敏捷當中，ScrumMaster和團隊成員都是平級的，不存在任何上下級關係。他雖然會承擔一部分傳統專案經理的職責，但是他並不具有命令專案成員的權利，也不像專案經理那樣對專案的成敗負全權的責任。當然他們更不會過問團隊成員的績效考核，薪資等這些問題。他們是一個服務者，他們的服務要確保能夠滿足團隊最高優先順序的需要。據個例子，專案經理會問：“那麼，今天你要準備為我做什麼？” 相反，服務型領導的ScrumMaster會問：“那麼，為了幫助你和團隊更加有效，今天我能做什麼？”
ScrumMaster相關書籍：《Scrum指南》《Scrum精髓》《Scrum捷徑》《Coaching Agile Team》《Agile Retrosectives》《看板方法》《精義思想》《SAFe白皮書》
1.2 產品負責人
作為確保團隊作出正確產品以便幫助公司得到最高投資回報的產品負責人，在Scrum團隊中負責“做什麼”的問題。不同公司，不同部門，不同團隊的產品負責人的具體職責不盡相同。但是，從總體上來說，產品負責人的工作包括：願景和邊界。產品負責人的工作包括兩個方向：提出正確的解決方案和確保解決方案被正確“製造”。
產品負責人的職責是將開發團隊開發的產品價值最大化。產品負責人是負責管理產品待辦列表的唯一負責人。產品待辦列表的管理包括：
1.清晰的表達產品待辦列表項。 2.對產品待辦列表進行排序，使其最好地實現目標和使命。 3.優化開發團隊所執行工作的價值。 4.確保產品待辦列表對所有人是可見，透明和清晰的，同時顯示Scrum團隊下一步要做的工作。 5.確保開發團隊對產品待辦列表項有足夠深的瞭解。
產品負責人可以親自完成上述工作，或者也可以讓開發團隊來完成。然而無論何者，產品負責人是負最終責任的人。
Scrum組織中專案管理職責的對映，不過下面的表格是理想的狀態，實際情況可以根據專案情況適當的調整。
在專案開始的階段，產品負責人會參與組合規劃和產品規劃。組為組合規劃的一部分，產品負責人有可能要和組合經理和其他產品負責人一起討論可能影響新產品計劃的相關問題。在產品規劃過程中，產品負責人和專案相關干係人，使用者和客戶一起共同討論，一起構思新產品。做完這些以後，組織會從經濟的角度進行篩選，以確定開發工作是否可以得到資金，工作何時開始（批准資金）。接下來，當專案得到組織認可後，產品負責人需要參與制訂計劃的草案。這個活動一般包含一個故事寫作研討會，目的是產生一個可供版本規劃期間使用的概要產品列表。接下來，會再召開一個估算研討會，產品負責人也要參與，在這個研討會上，開發團隊成員會對高價值的故事進行評估。再接下來，會再召開一個會議，綜合考慮故事優先順序，範圍，估算，專案相關干係人共同討論，制定足夠的版本計劃，得到一個足夠清晰的整體版本，並對交付什麼，何時交付之類的業務問題給出初步解答。在確定版本計劃後，Scrum團隊就可以執行第一個衝刺了。接下來，我們說在每個衝刺中產品負責人的工作。在衝刺開始的時候，產品負責人負責提供帶有優先順序排序的產品列表（有完整的接受標準）並且回答團隊問題，以便制訂衝刺計劃。在執行衝刺時，產品負責人要隨時回答團隊對於故事的問題並且當特性完成時對特性進行測試。另外一方面，產品負責人還要與專案內外部干係人溝通會面，確保為下一輪衝刺設定正確的優先順序順序，並獲得對今後衝刺所選特性有影響的重要資訊。同時，產品負責人還需要對產品列表進行梳理，包括書寫新的條目，細化現有條目等。
產品負責人每日工作列表
產品負責人每天都要做以下這些工作。
1.每天開始都要檢查Sprint待辦列表裡的條目和相應的任務情況，如果有任何關於進度的疑問都需要追蹤。 2.協助團隊成員解決問題，澄清需求。 3.儘早評審已經開發完成的功能，確認功能是否是期望的。如果不是則需要決定是否要在本個迭代做出更改，或者放到下一個迭代繼續完成，或者需要建立新的使用者故事。 4.編寫新的使用者故事來完成更多的功能，並且向團隊澄清新的使用者故事。 5.編寫史詩級使用者故事（如果功能太大，單個使用者故事無法承載的話）。 6.報告任何你發現的軟體問題。 7.參加每日站會（如果你和你的團隊認為這樣有助於完成迭代目標）。 8.聽取並回答每日站會的三個標準問題。 9.發現需要你進一步跟進的任務。 10.和團隊分享有用的資訊。
準備計劃會議
收集足夠數量的待辦列表以便團隊在計劃會議上評審，並且按優先順序排好順序。 - 要以商業價值做作為排序的依據，同時考慮到風險，潛在失敗的可能性和其他相關的因素。 - 列表項的資訊裡要包含它與其他列表項之間的依賴關係。
計劃會議中
1.和研發團隊，ScrumMaster一起使計劃會議變得更有效。 2.產品負責人必須參加會議。 3.回到問題以澄清和解決有可能影響實施和估算的問題。 4.如果需要的話，需要更新使用者故事的主題和描述以避免歧義和誤解。 5.如果需要的話，重新更改使用者故事的排序以便Sprint可以更有效。
評審會議中
評審團隊在過去的一個迭代中提交的功能是符合期望，確定是否接受團隊提交的潛在可釋出增量。
回顧會議中
ScrumMaster主持會議，團隊共同決定產品負責人蔘與該會議是否對團隊實現目標更有幫助。
產品負責人小結：
產品負責人相關書籍：《Scrum指南》《Scrum精髓》《人人都是產品經理2》《使用者故事》《Scrum產品經理》
1.3 開發團隊
Scurm的開發團隊應該由T型技能的成員組成。所謂的T型的意思就是團隊的成員在廣度（知識結構和能力）和深度（專業知識）兩個維度都有發展。
在傳統的軟體開發方法裡，定義了不同的工作型別：軟體主任工程師，程式設計師，測試工程師，UI工程師，資料庫工程師。但是，在Scrum裡面定義了“開發團隊”的角色，這個角色是所有這些工作型別的集合。在Scrum裡面，所有這些人都被稱為“工程師”。一些Scrum成熟度很高的公司和團隊，甚至在和員工簽訂合同的時候也只是寫了這個員工是工程師，而弱化傳統軟體開發方法裡面的工作型別區別。
在Scrum的每個衝刺當中，開發團隊為了實現計劃裡的功能，他們必須完成所有的相關工作，包括產品的設計，開發，整合和測試。為此，他們必須具備完成這些工作的所有技能。區別於傳統開發方法裡的“只負責自己那部分工作”，作為一個整體，團隊對功能的實現負責。通過模糊title的方式我們希望能夠弱化傳統專案職能分工的“撇清責任”，促進團隊的內部集體協作的積極互動，當目標實現出現問題的時候，所有人都可以起到積極的作用。舉個例子，衝刺的最後難免測試的壓力會大一些，這時候有空於的時間的工程師都應該幫助做測試，無論你的專長是研發，架構，UI。只要有時間，有能力，就都要幫忙。最終我們是要組織這樣一個團隊：團隊成員擁有合適的技能，覆蓋各個領域，並且總體上技能有一些重疊，以便團隊有一定的靈活性。經理們有責任和義務去為團隊創造一個促進學習的增加技能組合的環境，不論是領域知識，專業知識，思考技能或者其他能力。經理要支援團隊成員花時間學習。
在自組織的團隊裡面，團隊成員通過討論達成共識並且最終制定規則和流程。由於每個團隊成員都可以對所有議題發表自己的意見而成為規則和流程的制定者，因此當最後達成一致意見後，團隊成員就會更加主動的去履行他們的承諾。在執行期間，通過每日站會和日常的充分溝通，如果有團隊成員在履行承諾的時候出現問題，其他成員也有充分的機會提醒和幫助他。在傳統的控制管理中，團隊成員是被動接受者，但是在自組織的環境裡大家是規則制定者，監督者和履行者，這樣的身份變化，導致所有團隊的成員都是團隊的“領導者”。
團隊需要具備的能力：產品，Scrum，架構，研發，手工測試，自動化測試，XP實踐，自動化整合和自動化部署，UI，資料庫。
需要外部支援能力包括：Scrum, 自動化測試，XP實踐，自動化整合和自動化部署，資料庫。
Scrum開發團隊每日工作列表
一天的開始
1.檢視目前衝刺的燃盡圖報表。 2.如果團隊落後於時間表，你需要確認自己是否可以幫助團隊追上進度（尤其是當你的手中的任務落後於進度的時候）。你需要確認所有你已經完成的任務在相關的系統和任務板上都標記為完成。 3.檢查今天你要做的工作。 4.如果你今天沒有可以做的工作，你需要和團隊成員一起找到你可以幫忙的工作。
一天當中
1.當你完成一個任務的時候，要立即更新任務狀態。 2.更新所有相關項的資訊。 3.如果你開始了一個新的任務，請把任務狀態更新成“進行中”並且填寫任務人。 4.如果你的任務完成了，請將任務標狀態記成完成。 5.更新完成任務需要的剩餘時間資訊。 6.完成你領取的任務，如果需要幫助，請不要憂慮，立即讓大家知道。 7.和大家一起寫作完成任務。和大家討論你的工作以便可誒完成任務。 8.參加Scrum每日站會。 9.彙報你的工作資訊。 10.從上次站會之後你都做了些什麼 11.你計劃在下次次會議之前都做些什麼 12.你遇到了什麼阻撓你工作的進度的需要他人幫助的問題。 13.確認是否可以幫助他人 14.幫助產品負責人完成需求的更新 15.回答產品負責人的問題並提供你的理解 16.編寫技術故事 17.報告產品缺陷（例如，你在完成任務進行的時候進行的驗收測試中發現的缺陷） 18.和產品負責人澄清Sprint待辦列表中的使用者故事的細節（越早越好）。如果使用者故事沒有按照產品負責人的期望完成的話，產品負責人會作出決定是否在當前迭代中立即修改或者以後在改。
一天結束時
1.更新你的工作狀態
2.檢視燃盡圖確認團隊工作進展
準備計劃會議
1.梳理產品列表（和產品負責人討論以澄清對條目的理解）
2.建立技術使用者故事
計劃會議中
討論並且估算每個列表條目
計劃會議結束後
在計劃會議結束後需要立即將使用者故事分解為任務。這對正確完成工作非常重要。 - 和團隊成員一起分解任務（所有的使用者故事和缺陷）並且提供任務工作量的估算。 - 對於新的團隊來說，這通常需要整組人員一起開會討論決定。 - 對於有經驗的團隊，做法相對靈活；可以一個人負責進行所有的估算，然後其他組員進行檢查以確保一致。
在評審會議上
團隊成員負責向產品負責人演示功能
在回顧會議上
1.在ScrumMaster的組織下，團隊成員一起回顧自上一個回顧會議以後的工作狀態。
2.在ScrumMaster的協調確認下，團隊成員一起確認下一個迭代團隊需要做的改進措施以及負責人。
Scrum開發團隊小結：
Scrum開發團隊的主要職責：
1.在衝刺執行期間，開發團隊完成創造性的工作，包括設計，構建，整合，測試，最終提供潛在可釋出的功能釋出。 2.每日檢視和調整（每日站會）——作為一個自組織的團隊，團隊通過每日站會來實現自我的檢視和調整實現衝刺目標。 3.梳理產品列表——幫助產品負責人梳理產品列表，細化產品列表條目，估算和排列優先順序。 4.衝刺規劃——在每個衝刺之初，開發團隊參與衝刺計劃會議。在會議上，根據產品負責人提供的資訊，對產品列表條目的工作量進行估算，並在ScrumMaster的指導下，與產品負責人共同制定衝刺目標。 注意，開發團隊對工作量的估算是有絕對話語權，作為一個自組織的團隊，他們不受其他角色的影響，對工作量進行估算並且按照自己的承諾去履行衝刺目標。
5.檢視和調整產品與過程——在每個衝刺結束的時候，開發團隊都需要參加衝刺評審會議和衝刺回顧會議。在會議上，Scrum團隊檢視和調整自己的過程和技術進一步改善團隊使用Scrum來交付業務價值的能力。
Scrum開發團隊的特徵：
1.自組織 沒有專案經理或者其他經理告訴團隊怎樣開展工作；團隊在沒有外部力量干預的情況下，為了共同的衝刺目標而工作，逐漸達成默契，相互理解，不斷改進。 2.跨職能 為了提交潛在可交付的增量，團隊需要具備所有相應知識和技能的成員。 3.規模適中 5～9人的規模。
1.4 實踐類問題
1.4.1 一個人能同時即做產品負責人又做ScrumMaster嗎？
絕對不能！產品負責人和ScrumMaster這倆個角色在Scrum團隊裡是兩個非常重要的角色。產品負責人負責產品要做成什麼樣，但不負責指導團隊。
ScurmMaster則負責另外一個維度的工作，即專注於幫助團隊以正確的方式和流程來執行Scrum專案。在團隊中，產品負責人代表組織對經濟利益的追求，
而ScrumMaster則代表團隊的利益。如果要求一個人來同時完成這兩個角色是很困難的，更重要的是經常會遇到這兩個角色出發點不同導致的衝突而無從選擇，‘
最終一個角色會凌駕於另一個角色之上，而是整個團隊利益受損。
1.4.2 Scrum裡任務是如何分配給團隊成員的？
團隊成員們一起識別，評估每一個使用者故事的工作量。一旦衝刺開始，每一個團隊成根據優先選擇他們認為合適的工作。
因此，我們說團隊成員自己給自己分配任務。具體的分配方法由每個團隊的成員一起討論而決定。
1.4.3 開發團隊可以有多少個人，為什麼要限制團隊人數
一個Scrum開發團隊可以有多少工程師？對於這個問題來說，並沒有標準的答案。2003年，Jeff Sutherland說一個Scrum開發團隊的人數不能超過7個。
現在，根據最新的《Scrum指南》，一個Scrum開發團隊的人數應該為3~9.如果團隊裡的人太少，團隊會面臨能力缺乏的困境。 雖然人越多，團隊能完成的工作就越多，但如果人太多了又會對團隊計劃，溝通和協調帶來巨大的挑戰。正如我們所知，
在IT專案中，越多的工程師並不能意味著可以帶來越多的產品功能釋出。而且經常會帶來相反的結果。如果你的專案有超過9個工程師的資源，
那麼請把他們分解成兩個Scrum團隊。而且，請不要忘記，Scrum強調的實驗！你的組織和專案團隊合適的團隊規模需要你自己去尋找。
1.4.4 如果專案工作太多，一個Scrum團隊做不完怎麼辦
正如我剛才所說，如果你有足夠的工作和足夠的資源，那麼就請你通過組建新Scrum團隊的方法來加速你的速度。如果你的工作太多但是資源不足，
那麼就請你通過給特性排列優先順序的方式，保證團隊只開發最重要的功能。
1.4.5 迭代和衝刺的區別是什麼
迭代的英文為Iteration。迭代是一個通用的敏捷術語，指的是單個開發迭代。衝刺的英文是Sprint。作為敏捷的一種方法的Scrum，衝刺是指Scrum的一個迭代。
1.4.6 為什麼在開發團隊只有工程師而不是開發，測試呢？
在Scrum裡，責任和成果屬於整個團隊。為了強調團隊的整體性，Scrum開發團隊裡只有一種角色，就是工程師。
但這並不意味著每個人都擁有相同的技能，或者是說做相同的工作。這也許對每個人未必完全公平。例如，一個初級工程師和高階工程師能力就不相同。
但是，還是那句話，Scrum強調團隊作為一個整體承擔責任。
1.4.7 產品負責人和ScrumMaster都是全職的嗎
為了保證Scrum團隊的工作，ScrumMaster和產品負責人需要有足夠的時間來完成他們的工作。一個比較常見的陷阱是，除了日常工作以外，
組織會給某個人分配產品負責人的新角色，讓他同時兼顧日常工作和產品負責人的角色。這樣做的結果通常都並不好。
我們比較推薦的做法是讓產品負責人和ScrumMaster成為全職的工作。
1.4.8 質量控制在Scrum怎麼體現
在Scrum裡，質量控制不是一個在產品釋出以後才執行的工作。相反，在Scrum當中，質量控制應該是包括在所有的從開始到結束的衝刺過程中。
在專案的每個衝刺開始的時候，團隊就應該注意如何檢查各個工作的進行。因此，我們說質量控制從使用者故事的定義就應該已經開始了。所有的功能和非功能的測試都應該被覆蓋到。
因此有人說，在Scrum團隊裡不需要一個叫做QA的角色。當然如果大家都認為有幫助的話，公司級別有專門的QA角色也是可以的。
但是我們要強調，在Scrum團隊裡面整個團隊對質量負責，而不應該將質量的責任只記在QA的名下。
1.4.9 新任ScrumMaster應該怎麼辦
美國第28任總統威爾遜說過：“如果你想樹敵，就嘗試改革吧”。對於大多數人來說，變化總是令人生畏。因為變化會把人從熟悉的環境拉出到一個充滿“驚嚇”的新世界。
因此，作為一個新任的ScrumMaster，你需要注意的是，在一開始請千萬不要急於求成，一股腦兒地改變所有東西。要有耐心，好好準備。
當準備好以後，慢慢開始，而且以開始的時候先引入一兩個實踐（例如Scrum的每日站會和修整產品列表），當取得了一兩個雖然小但有決定性意義的勝利後，再公開宣傳並且繼續改進。
1.4.10 Scrum的核心價值觀
怎樣才能通過挑戰團隊成員來確保團隊不會因為各自強烈的自我意識和持續不斷被的爭吵而分崩離析呢？最好的辦法就是所有的團隊成員都要有使用者Scrum的核心價值觀，
並且以此形成他們的職業特質。
Scrum的核心價值觀：活力，共情，好奇，友善，尊重。
1.4.11 開發團隊的人員配備
沒有一個放之四海而皆準的規則可以定義開發團隊的人員組成，因為專案和專案的都是各不相同的。如果你對團隊組建毫無頭緒，我向你推薦一個比例（當然需要你根據實際情況進行檢查和調整）： 2個研發，1個測試，0.5個專家（如果你的專案已經實現了高度的自動化，那麼研發的比例可以更高）。 專案之初，專案中的高階工程師和初級工程師的比例為2:1 (隨著專案進行這個比例可以降低)。 有Scrum經驗的成員與沒有Scrum經驗的成員比例為1:1.
1.4.12 一個ScrumMaster可以同時和多個團隊一起工作嗎
一個ScrumMaster可以同時在幾個團隊中工作這個問題有很多的討論。雖然，我們一直強調ScrumMaster這個角色很重要，全職的ScrumMaster對於Scrum團隊的重要性。
但是，我們必須靈活起來，根據2018年年年初公佈的最新的Scrum報告，一個ScrumMaster同時在多個團隊工作的目前已經成為一種普偏現象。
當然，如果資源允許，尤其是在團隊剛剛組建的時候，一個全職的ScrumMaster是最好的。隨著團隊的成熟，
同時擔任兩個團隊的ScrumMaster也是可以的（一個ScrumMaster服務於兩個團隊，是比較推薦的解決方案）。
如果Scrum團隊已經是自組織的，成熟的精英團隊，一個ScrumMaster可以為三個這樣的團隊服務。
1.4.13 Scrum有沒有一套流程，有沒有標準
對不起，Scrum不提供流程或者最佳實踐。Scrum的遊戲規則就是它的標準，這些都包含在《Scrum指南》當中。