從團隊技術負責人到Scrum Master或PO，我們需要從做決策轉為提問題。

一、2個關于估算的問題

團隊在進行項目前需要進行粗略估算，但這并不是要求團隊成員一定按照估算出的結果進行。

問題一：估算結果的單位是什么？

小時、星期、月等這些時間單位會出現重疊，如估算值為5個星期明顯長于估算值一個月。

“只要x個星期”的估算結果已經足夠做決策。一旦得出結果，這就需要團隊成員開始為項目做準備。

問題二：成員對按照估算完成有多大的信心？

團隊進行估算時，最至關重要的是團隊成員需要對這個估算結果充滿信心。如果團隊內超過90%的人對估算值充滿信心，那么估算值更具有可行性。

二、3個關于團隊決策的問題

Scrum Master或PO在幫助一個團隊做決策時通常會考慮以下問題：

問題一：我們在做決定前考慮過其他選項嗎？

問題二：未來可能遇到的的最糟糕情況是什么？

問題三：我們需要做些什么才能做出最佳決策？

這三個問題并不是每次團隊決策都要問，設計這些問題的初衷是發現團隊成員的不同見解。

三、2個關于開會的問題

問題一：在場的各位都需要參加會議嗎？

我們需要思考：如果缺少一兩個人，會議是否還能繼續？許多敏捷團隊過于追求團隊協作，團隊成員總會覺得無論什么會議都需要他參加，甚至與他根本無關的會議。

Scrum Master一方面需要感謝他們對協同工作的用心，另一方面需要需要建立相應的團隊規范，明確告知他們不需要出席每一場會議。

如果團隊成員在會議中不能創造價值或者沒有任何收獲，那么他參加這場會議就是無意義的。為了防止上述規定被濫用，這里需要注意一點：這并不代表團隊成員可以選擇是否參加這場會議，而且團隊作為一個整體是有權否決某個成員不愿意參加某個會議的想法。

第二個問題：除了在場的成員，還需要其他人參與會議嗎？

這是為了確定是否有人缺席會議。有些會議的重要性要求必須所有人到場，這些會議需要有更多合適的參與者來產生更多價值。

四、1個“閑逛”時提的問題

即便成為Scrum Master，傳統的走動式管理仍花費大量的時間在交流上。舉個例子，程序員和測試員在進行重要的談話，這時Scrum Master可能會走過去旁聽他們在說什么，并給出一些具有參考性的建議。

有時候，團隊成員之間的探討是有意義的，比如技術決策者應該了解程序員和測試怎么做決定。我們需要自問：這件事有必要讓其他人知道嗎？如果答案是肯定的，那我會盡量找到需要知道這件事的人，將信息同步給他。

五、1個在每日站會時提的問題

在每日站會中，Scrum Master或PO看到團隊的迭代燃盡圖，然后想知道他們如何在計劃的迭代結束時完成所有任務。但當問同一個團隊是都能夠完成所有任務時候，他們的回答通常都是肯定的。

這時候，團隊可能會出現預測不符合現實的情況，Scrum Master就需要團隊成員思考：我應該了解些我不知道的內容？?

Scrum Master可能得到“某個成員沒有更新工時”“進度目前雖然落后但很快會趕上來”等各種答案，詢問一些團隊成員都知道但我所不知道的事情，這能夠為同步“假設”提供很好的機會。

這個問題能夠展現出眾多不同的假設，從而找到出現問題的真實原因，以便大家達成一致，共同在迭代結束前完成所有任務。

總結

提問比陳述更能說明問題。

剛開始成為一名Scrum Master可能還沒有發現提問的作用，有可能會錯過了解團隊和他們工作內容的機會。希望發現這些問題的作用！