在成爲Scrum Master（SM）以前，我曾擔任過許多團隊的技術負責人。工做內容之一就是作決定，並且我認爲本身作得挺好：堅決果斷是我性格的一部分。程序員
然而，當我成爲Scrum Master以後，這樣的性格並無爲我帶來多少好處。我開始意識到，要想作一名成功的Scrum Master，我須要從作決策轉爲提問題。然而這不符合我一向的風格，在過去也未給我帶來任何成功，所以在一開始的時候我是很掙扎的。數據庫
可是，當我不斷從提問的過程當中受益時，我會很樂意和你們分享我最愛問的問題。其中大部分問題在團隊中都很容易被問到，不管你是Scrum Master仍是PO。學習
2個關於估算的問題測試
我常常會要求團隊進行一個粗略的估算，並非要求讓他們按照估算去作（由於我不是要求他們承諾，估算和承諾不是一回事兒）。我確實只是須要一個粗略估計。在這種狀況下要作得好，得這樣問：設計
我並非在要求一個具體的估算值，而是當我問你的時候你腦海裏浮現出的是什麼：幾小時、幾天、幾個星期、幾個月或者是幾年？blog
固然，我知道這些時間有些是重疊的——幾個星期可能就比一個月長。可是若是從團隊那裏獲得相似「哦，只要幾個星期」的估計時，一般已經足夠作決定了。包括可能要求團隊作出更確切的工做評估。ip
當我要求確切的工做評估時，我一般會問另外一個問題：團隊協作
你對這個估算有多大的信心？io
你在這裏要去發現他們對此抱有多大的信心以及團隊其餘成員是否同意，一個預估若是有90%的人抱有信心，那麼它極有多是精確的。ast
3個關於團隊決策的問題
做爲Scrum Master或是PO，有時候我會想知道團隊在作決定的時候作了哪些考慮。一般我會問這樣三個問題：
-
你在作出決定前你還考慮過其餘三個選項嗎？
-
若是咱們繼續按此方向進行，可能發生的最糟糕的狀況是什麼？
-
要作些什麼才能讓這個決定成爲最佳決策？
你可能不問這三個問題，也不在團隊每次作決定的時候問一樣的問題。你不問這些問題是由於做爲一名Scrum Master或PO，你有權利否認團隊的決定。可是，你一樣有義務去理解團隊對此決策的信心。
設計這些問題是爲了發現不一樣的看法，由於當你直接問「要作些什麼才能讓這個決定成爲最好的？」而有人回答說「全部事情」時，這就有可能會出問題。
2個關於開會的問題
我真的不喜歡開會。若是我被扔到一個一頭有蛇，另外一頭在開會的的走廊上，我不肯定本身會跑向哪邊。
因此我會盡可能將開會次數及參會人數保持到最少。並且在會議開始時我會問兩個問題：
-
在場的各位都須要開這個會嗎？
-
還有其餘人在這裏嗎？
問第一個問題是想看看若是少一兩我的這個會議是否還能繼續。我常常看見敏捷團隊過於追求團隊協做，成員總會以爲每次開會他們都須要參加，甚至是和他們不相干的會議。曾經有JavaScript的程序員參加了關於數據庫供應商發佈的最新版本是否值得升級的討論會。
若是你團隊成員對開會這件事過度熱心，那你須要感謝他們對協同工做的用心，可是要明確告知他們不須要出席每一個會議。
創建團隊規範，若是團隊成員在會議中不能創造價值或者沒有收穫，那他就不能參加這個會議。
固然，你必須明確告訴你們這並不表明他們能夠選擇每一個會議（要不要參加），以防止這個規定被濫用。最後，團隊做爲一個總體有權否決某人不肯意參加某個會議的想法。
第二個問題是爲了肯定是否有人缺席。儘管我真的很討厭開會，但有的時候會議真的須要不少人。
儘管我認爲開會和開會的人越少越好。可是有的會議是值得的，而這些會議由於有了合適的參與者而產生更多價值。
1個在「閒逛」時提的問題
在成爲Scrum Master後，我花了更多時間在交流上。這就是傳統的走動式管理。舉例來講，若是我看到程序員和測試員在進行一場重要的談話，我可能會走過去聽他們在說什麼，由於也許我能給他們提供一些幫助。（固然了，不要每次都走過去，尤爲是他們看起來是在討論私事的時候）。
有時候我聽獲得的討論多是對其餘人有價值的。好比我認爲一個技術做者應該瞭解程序員和測試員會怎樣作決定。因此我會問：
有其餘人須要知道這件事嗎？
若是答案是確定的，那我會盡可能找一我的將這些信息分享出去。
1個在每日站會時提的問題
在每日站會中，我會去關注團隊的燃盡圖，並思考他們怎樣在sprint結束時完成全部計劃。可是，當我問同一個團隊他們是否能完成全部事情時，答案一般是確定的。
若是我認爲他們的預測不現實，我會看着燃盡圖而且問道：
你知道我想了解的是什麼嗎？
我可能會獲得這樣的答覆：有成員沒有更新本身的工時。或者有人會解釋說他們的進度目前的確有點落後，可是他們已經學會了不少東西並且立刻就會提速遇上。（我發現這種說法不多實現，由於我常常聽到這樣說）。也許他們認爲正在加快速度，但我不是這樣想的。這是個發現不一樣假設的問題。
總結
提問比陳述更能說明問題
在我纔剛開始成爲Scrum Master，尚未發現提問的做用時，我常常錯過了解團隊和他們工做內容的機會。直到我發現了提問並認真聽取答案是學習的最佳途徑。
但願你也像我同樣發現這些問題的做用！
英文原文網址：https://www.mountaingoatsoftware.com/blog/nine-questions-scrum-masters-and-product-owners-should-be-asking