雖說敏捷開發關鍵在於每次的全力短衝剌，但無頭蒼蠅般的衝剌，是無法帶來價值的，還會讓團隊感到沮喪，所以在每次衝刺前，必須先舉行衝刺計畫會議，明確此次衝剌的目標，決定這次要完成的故事和任務是什麼，以及該如何完成。

Sprint 規劃會議

Sprint 規劃會議是一個 Sprint 的開始，這個會議通常是由 Scrum Master 召開，參與人員還有產品負責人與開發團隊，整個會議由二個部份組成。

(1) 要做什麼：挑選出一組交付物（通常是使用者故事），做為這個 Sprint 的承諾

(2) 要怎麼做：將要交付的使用者故事，進行任務拆解，以及點數估計

至於要花多少時間，Scrum 指南中的建議是，若週期為一個月的 Sprint，建議安排 8 小時的 sprint 規劃會議；週期為二個禮拜的 Sprint，4 小時的規劃會議是合適的，以此等比例類推。

Part I. 要做什麼？

前幾篇文章提到，PO（產品負責人）手中持有一些重要且已排序過的 Product Backlog，在 Sprint 規劃會議的開頭， PO 會從 Backlog 中取出希望此次衝剌所能完成的故事，排列好順序，逐一向團隊介紹他希望這次 Sprint 要完成哪些故事。接著團隊和 PO 討論這些故事的驗收標準是什麼，確保大家腦中想像的預期結果是同步的，重復以上的動作直到團隊無法承諾更多故事為止。整個過程中，PO 需要在場，以便回答各種問題，讓團隊能夠了解目標是什麼、為何而戰，以及凝聚共識。

Part II. 要怎麼做？

Sprint 規劃會議的下半段，我習慣把它稱做 Task Breaking Meeting (這個名詞應該不在 Scrum 中，是 Rson 觀察目前所在公司，其他 Scrum Master 的叫法)，因為這部份會比較偏技術要怎麼實現的拆解討論，PO 可以忙別的事偷懶不參加。

這個 Part 一般會由 Scrum Master 帶領開發團隊，把上個部份選定的故事拆解成任務工作（Task），比如說 「Sign-in」這個故事，會被分解成 前端UI畫面、資料庫建置、新增資料、權限設定等工作任務。這裡想提醒大家的是，故事才是交付物（此處例子為 Sign-up），任務則不是交付物，因為故事才是對 PO、使用者、或利害關係人有價值的東西，若一個故事沒有完成，哪怕是已完成了 99.8787 %，都還是半成品，價值有限。

實務上，就算團隊已盡力拆解出完成這些故事所需的工項，但還是有可能會有漏掉，不過別擔心，當 Sprint 啟動後，在做到一半發現時，認命再加進來就好（雖然 PO / SM 此時會很抖）。一般而言，效能不錯的團隊，能夠在 Task Breaking Meeting 時確認七八到八七成左右的工作。而且隨著團隊每個人的能力不斷成長，一次會比一次更有經驗，考慮的也更加周詳。若發現每次 Sprint Plan 都會估錯，那建議此時 Scrum Master 要嗅到不妙，尋求更有經驗的 Technical Lead 加入團隊，讓 Junior 可以在與 Senior 一起工作中吸取到經驗與建議，於實踐中成長。

拆解完一個個的任務後，許多團隊會繼續進行估算，這樣做的目的是能夠提供一個可預測性的參考。詳細可參考 <都說要估算，但怎麼估始終是個謎> 一文。

你可能會問，要怎麼推測一個團隊到底能有多少開發量能呢？這裡推薦我們團隊所使用的技巧，我稱它叫做「過去的點顛」（Rson 裝可愛？），這個方法是每次 Sprint 結束時，都將攻城獅在該次 Sprint 中所有完成的點數記錄下來，並計算平均值（若擔心被極端值影響的話可取眾數），如此就能知道團隊以及成員大概一個 Sprint 能夠有多少的 Capacity，且這個數值也會隨著一次次的 Sprint 不斷反應出成長或消退的效能。

那麼，什麼是估完點後理想的結果呢？這就沒有一定了，剛好符合團隊的點數能耐，或超過個一到二成，這二種結果各有優缺點，若老闆看團隊的績效是看有沒有都完成故事，前者就能鼓舞到團隊，也確保了所謂的「高績效」；若這公司的文化是倡導自組織，不太在意傳統的績效指標，那麼後者就會是比較好的選擇了（跳一下勾的到的目標，比較能夠讓團隊脫離舒適圈進入成長圈，逐漸擴大能力，就像忍者哈特利的訓練方式一樣）

Sprint 規劃會議的產出物－衝剌清單

當所有的規劃完成，點數也估完了，一切準備就緒，Scrum Master 就會將這些項目匯整成衝剌清單（Sprint Backlog），與團隊一起向產品負責人說，我們準備好了，而產品負責人代表業務方，也要做出一些承諾，在 Sprint 開始之後，不能再追加故事，除非團隊提早做完主動提出請求，或 Sprint 因特殊原因被要求異常中斷。

基本上，若 PO 沒有鎖定並保護 Srpint 、讓團隊得以在一段時間內安心開發的 Sense 的話， Scrum Master 就需要出來阻擋。 (當然，這是理想世界的 Scrum，我們工作的地方可是最懂得「靈活變通」的台灣公司裡呀，所以實際上還是得看所在組織的敏捷成熟度如何，「靈活對抗」之)

一切就續後，這次的 Sprint 衝剌就正式開始嘍！