Scrum立會怎麼開？把握3/3/4原則，讓立會簡短又有效！
Scrum立會超過時間，通常不是因為不知道要做什麼，而是做了一些多餘的事。這次要分享的是Scrum立會的3原則，與該避免的4件事。
這篇文章想說什麼？Scrum立會，是除了規劃會議以外最重要的事情之一，因為Scrum的精髓是即時地「掌握現況」、「彈性調整」、「相互幫助」，而每日立會就是為了做到這三件事而生的。立會說來容易，但真正執行時卻很容易開不完，甚至流於形式。因此，這次想聊聊該怎麼樣開立會，才能縮短時間，又能真正達到Scrum立會的目的。讀完這篇，你會知道什麼？1.Scrum立會的3個目的、3個原則、4件應該會發生的事
2.Scrum立會不該做的4件事
3.立會前該有的準備這篇文章雖是為Scrum寫的，但對於一般公司的晨會、周會報告也會有幫助。
如果想先了解Scrum，可以參考：《什麼是Scrum？不是工程師也能懂的Scrum入門介紹！》
什麼是Scrum立會？
Scrum立會，是在Sprint期間的每個工作天，由Scrum團隊全員參與的一場會議。它的原則是：要在每天的固定的時間（例如：10:00am）只花15分鐘、用相同的方式進行會議。
3個目的
這場會議十分重要，因為它就是為了Scrum的3個目的而生的，為了
- 讓PO可以「彈性調整」任務，決定是否繼續執行，或新增任務
- 讓團隊「掌握現況」並讓夥伴「相互幫助」
- 確保當前執行的任務「和目標保持一致」
3件事情
為了達到這三個目的，Scrum立會被設計由所有團隊成員，每天花15分鐘站在一起，手上不拿任何東西、看著Scrum board，輪口頭報告三件事：
- 昨天我完成了哪些Scrum board上的事
- 今天我打算做哪些Scrum board上的事
- 昨天或今天，發生了哪些會阻礙團隊、個人執行任務的事
兩手空空站著開會，是為了讓大家累一點，就會想讓會議快點結束，因此也會更精簡地報告自己的狀況。
4種情境
但這場立會比較特別的是，所有人都是積極回應的一方，任何人在報告時，都可能會產生以下4種狀況：
- 團隊成員對問題報告內容不清楚，會立刻提問
- 團隊成員聽到某個問題，而他有能力解決，會馬上說「我可以幫忙，等等我們來討論」
- PO、SM發現有人做錯了、不在軌道時，會即時說明、調整任務
- 如果有問題被留下，SM會負責記錄下來
依據我們團隊幾次衝刺的經驗，要知道什麼是正確的Scrum立會其實非常容易，任何一本書、網路文章都能清楚的說明。
但我發現，並不是因為我們不知道怎麼開會，立會才開不好，而是在開會時做了不少額外的事，才導致15分鐘的立會開到30分鐘，甚至超過1小時。於是，這次重點是想聊聊，「什麼樣的會議不是Scrum立會。」
Scrum立會不該做的４件事
我們團隊在歷經幾次波折之後，我總結了最常讓立會超時的4件事，並說明比較適合的解法，就讓我來一一說明吧！
1.不該討論如何調整Story、Task
不論是討論「Story與目標」、「Story與Task」之間的邏輯到底合不合理、是否要繼續進行、調整方式等，都不適合在Scrum立會上進行。
Why not?
其實，會議的類型分為很多種，任何的討論會議（例如規劃會議、回顧會議），都是屬於邏輯判斷、問題研究的會議，它需要花費許多時間、腦力、精神，而且很可能沒辦法產出理想的結論。
但相反的，Scrum立會主要的功用在於「資訊交流」，是單純的發出訊息、吸收訊息而已。
只要沒辦法當場下決定，需要一點時間討論、釐清的事，都屬於邏輯判斷、研究的會議，不該在Scrum立會上出現。最好是另外約時間，來進行這些討論，否則就讓精巧的立會失去本來的用意了。
另外，每個Story、Task，都是經過PO、DV在規劃會議時深思熟慮後的成果，要盡量避免用短短2、3分鐘就擅自更改方向與目標，不然會很容易做出錯誤的決策。
．
2.不該直接進行救援
只要是提供解決辦法、提供想法與意見等，都算是直接救援，也都不該在例會上出現。
Why not?
既然Scrum立會主要的功用在於「資訊交流」，「解決問題」當然就不會出現在立會。但並不代表團隊不該相互幫助，立會上比較好的幫助方式是說：
「好，這個問題我可以解決，我們等等處理」
「這個問題好像有點難，立會後詳細跟我說明一下好嗎？」
當然，簡單的是非對錯，只要能在30秒~1分鐘內解答的問題，就盡量解決，但如果是需要詳細釐清、說明解法，都應該另外找時間來進行。
．
3.不該分享成果
不論是展現昨天的Story或Task成果，都不該在立會上出現。
雖然Scrum立會主要的功用在於「資訊交流」，但目的仍是在掌握狀況、解決困難。如果要表示自己的進度，只需要向大家口頭說明：「我完成了xxx」即可，不需要展示任何畫面、功能等成果。
．
如果擔心自己的成果和大家期待的不符合，應該回頭看每個Story所設定的完成標準，照理來說，當初的Task是依據Criteria來撰寫的，只要Task做完，應該都代表Story已經完成。
如果仍然擔心，只需私下給PO確認即可。相反的，PO如果要確定完成狀況，應該是會議結束後，私下跟DV拿成果才對，不用浪費時間展示給所有人看，可以等回顧會議時再來分享就好。
就算是最差的狀況，某Task的成果有問題，照理來說也會在下一個有關連的Task進行時被發現，最遲也會在隔一兩天的立會上就被揭露。
所以展示成果，還是私下討論，或等到回顧會議吧！
．
4.不該改善Scrum流程
只要是調整報告方法、制度、內容，或是任何異動立會本身的事情，也都不該在立會發生。
這就像前面提到的Story和Task的調整一樣，我們不該擅自調整經過詳細思考的結論，Scrum流程也是如此，不該在立會上被任意更改。
另外，大家適應報告、工作模式，都需要一小段的接軌期，只要有所改動，很容易因為不熟悉的關係，讓會議開更久。
我的建議，如果PO、SM想要改變一些原本進行的模式，都應該要另外找時間和團員說明清楚，大家才知道該怎麼做，最快也要等到下一次的立會才能進行新的模式，如果時間允許的話，在下一次Sprint的時候再使用更適合。
．
Scrum立會是流於形式的報告？
我常聽有人說，Scrum立會容易變成一個流於形式的報告，其實有這樣的成果才應該表示開心呢！因為這代表這個團隊做對了8成以上Scrum立會要求的事。怎麼說呢？
因為所有的「傳遞與吸收資訊」會議，本質上都流於形式的報告，如果超出形式，只代表大家做了一些多餘的事罷了。所以，在Scrum接軌初期，大家應該更期待Scrum立會是流於形式的報告才對。
不過，這也並不意味著Scrum立會只是個形式。Scrum立會與一般會議的差別在於，會有人積極去了解狀況，並在了解狀況之後，說
「好，我等等替你解決」
「好，等等我們花時間來討論」
即便真的沒人可以解決，最起碼每個人都會知道情況，問題也會被SM記錄下來。
．
Scrum立會，是個質量非常高的會議，因為它用最簡端的方式，表達最充足的資訊，並且允許進行最小、但有十分有意義的互動。
也就因為它不做多餘的事情，才能讓每一句話、每個動作都深具價值。
．
Scrum立會前，還需要的充足準備
立會就只有短短的15分鐘，我們該做的，其實就是排除一切會讓人分心的事情，專心地「傳遞與吸收資訊，並進行最精簡有效的互動」。
每個人都該在立會前，充足地準備要報告的內容，並在會議進行時，專心理解他人目前的狀況、發生什麼樣的問題，並盡其所能提出解答。
另外，如果能在立會前，再次提醒團隊Scrum立會的精神與做法，相信更容易做到真正簡短而有效的會議。
重點回顧:這次，我們提到立會的3.3.4原則，並知道了，我們其實沒有做錯，只是多做了些事情才讓會議變得冗長。1.不該討論如何調整Story、Task
不要利用回報時間，去探究正在做的事情到底是對是錯。2.不該直接進行救援
不要利用回報時間，去討論具體的方法。3.不該分享成果
不要利用回報時間，去說明細節的成果。4.不該改善Scrum流程
不要利用回報時間，去改變會議的進行方式。※延伸閱讀:>>【SCRUM工作術】文章總表
>> 什麼是Scrum？不是工程師也能懂的Scrum入門介紹！
>>【Scrum工作術】3個重要的核心精神！
>>【Scrum工作術】規劃會議怎麼開？完整的準備，讓時間縮短4倍！．「1下」拍手：到此一遊，留個記錄吧。
「5下」拍手：表示喜歡這篇文章。
「15下」拍手：表示你想要知道更多相關的內容！
「30下」拍手：手應該會有點痛，但還是歡迎繼續拍。按下「Follow」，追蹤我或我的專欄，將為您定期提供更好的文章！
