今天我們來一起聊一聊Scrum中的計劃會議。

那麼，首先，scrum中的planning會議的目的是什麼呢？

其實從本質上來說，scrum中的planning會議主要有以下幾點

• 從PB（Product Backlog）中按照優先順序選取這個sprint需要做的item
• 團隊澄清user story/item的需求，並且決定是否將該user story拆分至更小
• 團隊估計user story的點數（工作量）
• 團隊可以根據實際情況決定是否將user story拆分成task來進行track
• 決定該sprint的目標和要deliver的user story（實際在這個地方，團隊很大程度上是對PO的一個承諾，這個後面可以詳細跟大家探討一下）

那麼從上面幾點可以看出，實際上從sprint角度來分析，planning meeting主要做的就是==建立sprint backlog==, 並且將sprint backlog對映為在這個sprint裡面team member的工作任務。

好了，既然我們知道了planning meeting的目的，那麼都有誰來參加sprint backlog呢

其實所有跟正在開發的產品相關的乾洗人都可以參加planning meeting,但是要在planning meeting之前確定參會人名單，並且根據不同干係人對專案的關係來決定他們在會議上的角色。這樣才能確保planning meeting能夠正常有序的進行，而不被意外因素所打擾。

那麼怎麼樣來保證一個高效的planning meeting

1. scrum master要把握會議的程序，儘量保持團隊的討論集中在planning meeting的目的上。舉個例子，團隊成員往往會針對user story的一些細節問題討論不止，但是planning meeting不是討論需求細節的會議，所以這個時候SM要考慮是否介入討論，將會議拉回到正確的軌道上來。
2. 估故事點的時候，儘量讓所有團隊成員都參與，儘管有可能某些團隊成員並不真正參與這個故事，但也最好進行參與估點，這樣能夠確保團隊成員的 參與性，防止會議成為幾個人來做決定，其他人知識跟隨者的情況。
3. 故事要被拆分成合適的大小，這樣才能更好的估計故事點，“實現一個部落格”和“實現一個可以登入的頁面”哪個更好估計點數一目瞭然。
4. 團隊要根據velocity和available來承諾給PO的delivery，如果是一個新的團隊，無法用velocity來承諾，那麼可以考慮根據團隊的實際能力來進行預測。
5. 一定要跟團隊align planning meeting的會議目的，建立團隊成員對於這個會議的安全感，特別是在剛開始進入敏捷的時候，防止團隊將這個會議單純的考慮為跟團隊leader做commitment。

那麼一般下來planning meeting要用多長時間呢？

一般來說，對於4周的sprint，我們一般時間小於8個小時，2周的sprint需要不多於4個小時的時間，但是實際執行下來，往往團隊會對於這個會議所需時間有一些要求，一般2周的sprint不超過2個小時為最好，如果時間過長，可能會造成會議過於拖沓，而且大家極易疲勞。
但是如果確實有需求沒有澄清的話，還是要根據實際情況，儘量在站會上溝通清楚。

user story一定要拆分成task麼

個人理解，user story要拆分成task的主要意義在於能夠按照更小的粒度來對user story在一個sprint裡面進行跟蹤，並能夠及時的解決對應出現的問題，而且從task一般用hours來進行估計的情況，可以更好的更新burndown chart等工具。所以可以根據實際情況來定，以兩週的迭代來說，如果一個user story所需時間小於3天，實際上是可以不用拆分的，如果大於三天，根據經驗會延期或者出問題的可能性很大，所以最好拆分一下。

團隊在planning meeting上pick up的user story是承諾麼

從新的scrum primer上，已經更傾向於用承諾來代替預測在計劃會議上了，實際上這也是scrum在執行到現在的一個明顯跟現實環境的妥協和改變，在最早的scrum簡章裡面，實際上是不想使用承諾這個詞的，因為scrum對於變化的不確定性，還有故事的不可預估性，是不希望團隊在每個sprint開始就對ＰＯ做出承諾，因為ｓｃｒｕｍ是希望團隊在不停的改進和迭代中達到對於ｔｅａｍ交付能力的一個準確估值。但是實際上，在現實開發環境中，產品經理／ＰＯ往往希望團隊一開始就進行精確估值，從而能夠更好的控制開發進度和風險，所以這個就需要團隊在估值的時候，實際上是某種程度對於ＰＯ的一個承諾，很難說這種改變是好還是不好，但是由於對於實際環境的適應，所以也不得不進行相應的改變。實際上在現在的ｓｃｒｕｍ中，有一些已經引入了一些管理的概念，這也是ｓｃｒｕｍ本身不短適應變化的一種體現吧。

計劃會議不僅僅是在每個sprint開始的時候才進行，在整個產品/專案開始的時候可以有專案計劃會，release開始的時候也可以有release planning(grooming)來建立整個release的backlog。當然了在不同的層次，planningmeeting所需要的時間和關注的重點也不一樣，需要大家注意和調整。