一般情況下，一個Scrum Master如果更多的是做組織會議、確保時間盒以及對流程中的障礙快速響應等事項的話，可以同時引導2-3個團隊。在這種情況下，團隊會在降低問題發生率的基礎上提高一定的績效。

但如果Scrum Master想要將一個團隊打造成讓所有人都眼前一亮的敏捷團隊，那就需要考慮如何成為優秀的Scrum Master，以及如何更好地引導團隊。這時的Scrum Master最好是成為某一團隊（尤其是在團隊初創階段）的全職引導者。

接下來是一個Scrum Master的檢查清單，來看看Scrum Master要從哪些方面入手引導團隊吧：

一、產品負責人做得如何？

Scrum Master可以在很多方面提高產品負責人的效率：

• 不論有幾個團隊，一個產品是否只有一個產品負責人？

• 產品待辦事項列表是否根據產品負責人最新想法進行優先順序排序的？

• 待辦事項列表是不斷更新的，新反饋的需求是否已經放入產品待辦事項列表？

• 產品待辦事項列表的數量是否可管理？為了維護可管理的待辦事項數量，需要將高優先順序待辦事項的顆粒度細化，低優先順序的事項可以保持一個粗顆粒度的狀態。過度分析優先順序不高的待辦事項會適得其反，因為需求是在不斷變化的。

• 需求（特別是處在高優先順序的）是否能表述為獨立的、可磋商的、有價值的、可估計的、小的和可測試的使用者故事？

• 產品負責人是否在關注並避免技術債務的問題？比如在待辦事項的“完成”定義中加入自動化測試和重構。

• 待辦列表是否對所有利益相關人可見？

• 團隊成員是否都瞭解如何使用自動化工具來管理待辦列表？因為自動化工具的不正確引入往往不利於協作。

• 是否能夠透過更為宏觀的視覺化方式來促進資訊傳播？

• 有沒有幫助產品負責人梳理待辦事項的優先順序？

• 所有的利益相關人（包括團隊）是否知道釋出計劃與團隊現有速率的符合情況？可以嘗試在每個Sprint回顧會議上，確認專案已經“完成”後演示產品或釋出燃盡圖。這會讓我們更及時地發現範圍和時間的偏差。

• 產品負責人是否會在Sprint評審後調整發布計劃？一些產品負責人會在Sprint交付後，及時調整發布計劃。因為在這一過程中會 不斷地發現其他重要工作，一些原有工作會被推遲釋出。

二、 團隊做得如何？

• 團隊的狀態是否流暢？一般流暢的團隊會呈現以下特徵：

• 明確的目標（期望和規則清晰可見，目標可以實現，且與個人的技能和能力適當匹配）；

• 全神貫注並全力以赴；

• 在下意識狀態中，行動和認知相統一；

• 直接及時的反饋（行為可以隨反饋不斷地進行調整）；

• 在能力與挑戰尋求平衡（不要太容易也不要太難）；

• 控制力： 對形勢和任務的控制力；

• 存在內在激勵，因此工作起來很輕鬆。

• 團隊成員是否相互合作、相互理解，並經常一起慶祝專案成功？

• 團隊成員是否相互以高標準監督、相互挑戰以促進成長？

• 有沒有一些話題因為大家感覺難受，所以在團隊裡沒有進行討論的？

• 是否嘗試過透過不同的形式和地點做Sprint回顧？

• 團隊是否在Sprint中一直關注驗收標準？考慮一次在Sprint中期檢查來重新評估Sprint計劃。

• Sprint任務是否反映出團隊實際在做的事情？與Sprint無關的工作是Sprint的障礙。

• 團隊是否由5－9個跨職能人員組成？能否來構建潛在的可交付的產品增量？

• 團隊的任務板是否包含最新資訊？

• 團隊用於自管理的工件（任務板、Sprint燃盡圖等等）是否對團隊可見？方便使用嗎？

• 這些工件是否受到充分保護，不受外界干涉？團隊外部的人對團隊日常活動的過度審視可能會阻礙團隊內部的透明化和自我管理。

• 團隊成員是否會自願領取任務？在Scrum團隊中，應該感覺自己就像得到了報酬的志願者。如果沒有這種感覺，那一定是哪裡出問題了。

• 償還技術債務的需要有沒有放在待辦列表裡？如果沒有的話，團隊有沒有和產品負責人溝通？

• 團隊成員能否拋開各自的崗位定義，對約定工作的所有方面（測試、使用者文件等）集體負責？

• 管理層是否以集體的成功來衡量團隊？

三、工程實踐做得如何？

• 團隊開發中的系統是否有一個“按下測試”的按鈕，讓每個人（同一團隊或不同團隊的）都能方便地檢測到系統被破壞了？通常可以使用XUnit框架（JUnit等）來實現。

• 是否自動化的端到端系統測試（或功能測試）與自動化的單元測試之間尋求適當的平衡？

• 團隊是否用開發系統的同種語言來寫系統功能測試和單元測試（而不是用只有部分團隊知道如何維護的專用指令碼語言或捕捉回放工具）？

• 團隊是否發現在系統測試和單元測試之間存在有用的灰色區域嗎？

• 當有人引起迴歸失敗時，是否有個持續整合伺服器會在一小時甚至幾分鐘內自動發出警報？

• 是否將所有測試彙總到持續整合伺服器的結果中？

• 團隊成員們是否發現了持續設計和不斷重構的樂趣？重構有一個嚴格的定義：改變系統的內部結構而不改變其外部行為，且在存在重複的程式碼、複雜的條件邏輯、糟糕的命名識別符號、物件之間的過度耦合等情況下進行。重構應該連續進行，至少每小時進行幾次。只有在自動化測試覆蓋的情況下，才可能有信心地進行重構。

• 產品待辦事項列表的“完成”的定義是否包括完整的自動化測試覆蓋和重構？測試驅動開發（TDD）可以增加實現此目標的可能性。

• 團隊成員是否大多數時間來結對程式設計？結對程式設計可以顯著地增加程式碼的可維護性，並減少Bug率。

四、團隊/組織做得如何？

• 團隊之間是否有充分溝通？Scrum of Scrums是實現溝通的一種方式？

• 團隊在需要跨越架構邊界的情況下是否能夠獨立交付工作？

• 是否在組織內進行全面回顧以解決跨團隊、系統的問題？

• 在適當的時候，是否有將團隊障礙有貼在研發主管的辦公室牆上嗎？這些障礙帶來的浪費是否能被量化為失去的錢、投入市場的時間、質量或者客戶線索？

• 團隊或組織是否是為數不多的能提供和團隊集體目標一致的職業道路的組織？如果是以犧牲測試、自動化測試或使用者文件為代價來做程式設計或架構工作，請回答“否”。

• 團隊或組織是否被專業刊物或其他獨立來源公認為最佳組織或行業引領者？

• 是否在建立學習型組織？

像Scrum Master一類的創造性的工作沒有一個標準實踐，上面列出的點可能會幫到Scrum Master，也有可能幫不到。不過，一旦Scrum Master開始意識到自己可以做些什麼來改變現狀，儘管可能不敢去做。但沒關係，你已經走上了一條成為優秀Scrum Master的道路。