【Scrum精煉會議】規劃會議如何準備，才能讓時間縮短4倍？
規劃會議可以說是Scrum的起點，良好的會議需要不少準備，這次提供3個要點，希望能讓您的規劃會議進行得更順利。
這篇文章想說什麼?對於新手團隊，如果沒有一個經驗豐富的Scrum master，有時會在規劃會議就卡關了，而我們團隊就歷經這樣的艱辛過程。這篇文章，想要試著告訴大家，在Scrum中的第一場規劃會議前，應該要有怎樣的準備，才能進行一場良好的Scrum會議。讀完這篇，你會知道什麼?1.Scurm規劃會議前，應該要有怎樣的準備
2.怎樣的Story是好的
3.怎樣的Story是有問題的
失敗的Scrum規劃會議
相信讀到這篇文章的人們，應該已經看完基本的Scrum介紹，甚至已經有了自己的Scrum團隊。
如果還沒，建議先讀以下文章:1.什麼是Scrum？不是工程師也能懂的Scrum入門介紹！
2.【Scrum工作術】3個重要的核心精神！
但當真正的挑戰，卻是從規劃會議開始。
會議開了7.8個小時，卻連遲遲無法決定待辦事項
要做的事情太多，難以決定優先順序
要做的項目太少，連一週的工作時數都不到
這是新手團隊可能面臨的問題，更慘的是，好不容易完成規劃會議，但到了隔天，無法執行，仍然需要確認事情、討論想法。於是，又開啟了更多的會議，這其實就宣告規劃失敗了，所以才需要更多的討論。
以上，都是真真實實，發生在我們團隊的經驗，這也是為什麼我想寫這篇Scrum文章的原因。
為什麼Scrum規劃會議開不好？3個必須知道的事前準備
規劃會議開不好，往往是沒有掌握到執行Scrum前應該有的準備，以及它的核心精神，以下就來聊聊3個很容易被忽略的問題。
1. 沒有「執行方向、邏輯策略」
你知道為什麼工程師團隊，為什麼進行Scrum通常能比一般團隊順利嗎？
例如要開發一個電商購物車功能，通常是已經跟客戶確認需求，而有明確需求、有規格清單、白紙黑字有合約之後，軟體才會進行開發。
但這個「需求確認」，往往就是Scrum規劃會議能成功的關鍵。
但一般的行銷、業務、新產品團隊，很難在一開始就知道這份規格清單，而是從企業內部發想出癌的，但這樣的發想，卻很可能失去方向。
我們先來看看，在沒有制定策略與方向的情況下，Scrum規劃會議產出哪些Story：
1.身為一個管理者，我希望雇用清潔阿姨來公司打掃，讓我們的工作環境保持整潔。
2.身為一個行銷人員，我希望舉辦一場消費者體驗活動，讓客戶更了解我們的產品。
3.身為一個工程師，我希望進行購物車的bug修正，以便客戶能有更好的產品體驗。這些故事有沒有錯？當然，基本上沒有。
但下一步的討論通常是，清掃公司有那麼重要嗎？為什麼一定要辦體驗活動？購物車真的有人用嗎？
這些疑問其實都代表著：
「我們不知道這些事情是否真的重要。」
．
這樣的情況會發生，其實是因為PO在一開始，就沒有定義出哪些事情是重要的，並且決定走向、優先順序。
規劃會議之所以進度緩慢，很可能是因為沒有人知道要往哪個方向前進，當然就會去質疑所列出來的Story，花費的時間就不是在討論「如何」，而是討論「為什麼」，但討論為什麼，就不是規劃會議要做的事情了。
．
在開始規劃前，如能有個方向，例如：
公司目前的營運、客戶反饋都十分良好，但數量、營收都上不來，因此，需要讓更多人知道我們的產品。Story才更容易圍繞同一個主題：
1.身為一個行銷人員，我希望能拍一支youtube影片，來做為宣傳的媒體素材。
2.身為一個工程師，我要建立一個折價券系統，以便給行銷人員作為推廣工具。．
總之，一個規劃會議的起頭，永遠都該有個想達的目標，而這個目標應該由PO來制訂。這樣的起頭，其實也呼應著Scrum的本質：
「聚焦，並用最快的速度完成目標。」
（如果你還不知道目標怎麼決定，也許可以參考OKR實戰手冊系列）
Backlog List 無法展開「具體行動」
訂出規劃會議的目標，是PO的責任，但Task的良率，是影響執行的關鍵，PO、DV最好一起回顧每個Story，看著每個項目問自己：
「是不是看完Story之後，就可以馬上列出task，並開始動手做 ？」
規劃會議的本質，就是要「規劃」該做的事情，然後才開始做。但如果不能預期該有什麼結果、花多少時間、該如何做，就等於是沒有規劃了。
那麼，什麼樣的Story才能讓人馬上動手？
先舉個Story好了：
「身為一個管理團隊，我要一份行銷計畫書，以便讓行銷人員執行。」這個Story看起來沒什麼問題，但在列舉Task的時候，可能就只有2個Task：
1.蒐集資料2小時
2.撰寫企劃書6小時於是，在執行的時候，被分配到任務的人就會發現，他需要思考計畫書的架構、頁數、行銷方向，甚至還要和其他人開會討論…
最後，發現6小時完全無法完成。正確來說，他其實是
「不知道要做到怎樣的程度才算完成。」
那麼，什麼樣的Story是看完就能馬上動手的呢？
「身為一個管理團隊，我要完成一份行銷計畫書，以便讓行銷人員執行。」這個Story確實沒有什麼大問題，但卻缺少了「Story完成的狀態」，也就是說，我們得知道：
「達到什麼條件，計畫書才算完成。」
例如可以設定這個Story的完結為：
1.必須有一份15頁的計劃書電子檔
2.必須配合3張以上的圖片舉例
3.架構包含:行銷目標、預算、5個行銷案
4.經過3個不同部門的主管認同有了條件限制、具體成果，真實的task才有機會浮上檯面：
1.列舉5個行銷目標(1hr)
2.與3位主管討論行銷目標、本次預算，並選定其中一個(1.5hr)
3.依據行銷目標，研擬2個行銷專案，並蒐集資料(3hr)
4.依據行銷目標，研擬3個行銷專案，並蒐集資料(4.5hr)只有像這樣可以馬上動手的Story，規劃會議才有意義，所撰寫的Task才有辦法執行，並在執行完後，得到所有人的認同。
Scrum Master無法掌控會議
新創團隊還有一個很容易發生的狀況，就是因為人手不足的關係，Scrum Master就是開發團隊中的一員。
由於開發團隊思考的，是如何解決問題、如何做這件事，整個腦袋都在進行創意與邏輯的思索。
然而，SM想的卻是：我們是否有在軌道上？現在討論這個問題是對的嗎？下一步我們團隊是不是正在卡關？
所以如果可以，會建議盡量不要讓SM同時身兼DV，作為獨立個體來輔助。不然，就是要大幅降低其工作量，等大家都熟悉Scrum模式之後，再讓他接手多一點的工作。
．
但不管Scrum Master由誰擔任，我們都該盡可能讓他發揮價值。我認為最好的做法就是「尊重，並且優先讓SM發言。」
如果把Sprint衝刺比喻成一段航行，PO猶如業主，要定出這次航行的最終目標，及中途要完成的項目；DV猶如船上的水手們，會一直忙碌地幹活，確保都做都該做的事；SM的角色，比較隱晦，但它總是會在暴風雨、突發狀況、迷失方向的時候出現，協助大家釐清現況、互助合作。
回過頭來說，規劃會議之所以冗長無用，也有可能是SM沒有做到該做的事，例如：不知道現在會議是在哪個階段、要花多久時間、該討論哪些項目等。
所以，每次的規劃會議，SM都應該確認以下的狀況：
- 這次規劃會議的方向是什麼？
- 是不是每個Story都可被檢測，並且符合Story的特點？
- 這樣的Task清單，是否大家知道該怎麼做？
- 我們是否花太多時間，討論難以解答的事情？
- 我們現在是否在討論應該討論的事？
這些問題，都是為了確保團隊能依照Scrum運行。反過來說，如果團隊希望以Scrum方式運作，就必須要有能確認狀況的Scrum Master，並且團隊要能「尊重，並且優先讓SM發言」，才更容易與Scrum接軌。
我們團隊在進行了三次規劃會議後才終於理解，想要有好的規劃會議，需要更清楚的分工與對Story的熟悉。掌握上面三個概念之後，規劃會議從原本的2天將近16小時，到最後只需要花4個小時左右，就可以完全結束，並且讓衝刺順利進行。
在了解上述問題後，也許可以重新檢視規劃會議的成果，希望你能有不同的啟發。
「1下」拍手：到此一遊，留個記錄吧。
「5下」拍手：表示喜歡這篇文章。
「15下」拍手：表示你想要知道更多相關的內容！
「30下」拍手：手應該會有點痛，但還是歡迎繼續拍。按下「Follow」，追蹤我或我的專欄，將能定期收到優質的文章！期間限定！Notion 專案管理課｜直播開課
過往大多是小班制、私人企業的課程，這是一次有機會開放讓大家都能報名，如果對於目標、專案管理有興趣的朋友，歡迎參考！
