#Scrum 那些會遇到的大小事【二】– Sprint Planning Meeting

現實狀況，可能更為複雜且彼此環環相扣，本系列僅提供參考

簡介

Sprint Planning Meeting_[1]

• 參與人員：Scrum Team Members, Product Owner & Scrum Master
• 會議時間：分上下半場（WHAT-Meeting & HOW-Meeting），各約兩個小時
• 會議主要目的：
  • WHAT-Meeting —— 這個Sprint的目標是什麼？要完成什麼？
    PO定義該Sprint的目標、發表與解釋已預先挑選的Stories；團隊針對這些Stories提出問題、評估該Sprint的Capacity_[2]可以完成哪些Stories。
  • HOW-Meeting —— 要如何完成目標與任務？
    團隊將Stories個別轉化成多個任務，並指派每個任務負責人

---

# Planning Meeting總是開很久？

這個狀況可能與Grooming有間接的關係，可參考上一篇「Sprint Grooming Meeting」。另外根據Scrum機構建議_[3]，Story應該適時保有Priority與Point，為接下來的Planning Meeting做準備，如此一來就可以避免在WHAT-Meeting估Point而縮短會議時間。

如果反而是在HOW-Meeting耗時，可以檢討一下任務切割的方法，每個開發者習慣不同，所以沒有一定的標準囉（往後我會另外分享個人任務切割的方法～）

# Velocity真的有參考價值嗎？

過去參與的團隊，幾乎都直接忽視Velocity的重要性，可能它過於虛幻、不切實際或難以執行，導致無法體會到它真正的魅力。但要好好地發揮它，需要遵守前面提到的幾個概念：

1. 經常維護Product Backlog（調整Story的Priority與Point）
2. Commit Story時，有謹慎評估Capacity
3. 尊重且專注於當前承諾的項目

Velocity準不準確、是否有參考價值，幾乎取決以上的堅持，為什麼這麼說呢，以下分享過去的案例：

一個團隊，兩樣情

曾經與團隊的PM建議，是否可讓團隊試著堅持上述的概念跑幾個迭代（當時還沒正式跑Scrum，所以我們不會用到Scrum的關鍵字作為溝通），PM很Nice，而且我們是新的團隊，主管也願意讓我們試試。

於是，每當我們在評估時程時，PM有團隊的平均Velocity，每當新迭代要決定做哪些卡片時，我們會加總預計要做的卡片的Point來與Velocity進行評估，例如：

平均Velocity = 40 points
預計要做的Point總和 = 30 points

由於Velocity > 預計要做的Point總和，因此PM會再從他的待辦清單中抓幾個給團隊做。如果有其他狀況呢：

平均Velocity = P_velocity
預計要做的Point總和 = P_total

P_velocity 接近 P_total 時，團隊可以建議PM不要再加卡片，希望可以抓一點Buffer，以應付插件；或者團隊想要改進一些開發上遇到的問題（例如：文件不齊全、需要與設計團隊討論介面等等）

P_velocity 小於 P_total 時，團隊可以建議PM砍一些卡片，避免負載過高；或者團隊想要挑戰看看。

根據上述的狀況，PM與團隊獲得了一個溝通的依據。跑了幾次迭代後，Velocity會不停地修正，Velocity好不好用、適不適合團隊，大概就有一個共識了。另外一個好處是，主管可以參考Velocity，作為團隊績效與運行效率的評估（數據會說話）。

後來加入數名其他專案的同事，但由於我們不強迫每個人都要配合估Point，且他們已有個人的開發習慣與隸屬於不同組的Leader，所以新成員就沒參與估Point與參考Velocity。憑直覺估時程雖然很快，但通常是不可靠的，而且容易因為要趕時程，導致產品品質下降、累積可觀的技術債。

參考資料

[1][2] THE SCRUM FRAMEWORK TRAINING BOOK BY INTERNATIONAL SCRUM INSTITUTE™，第78頁
[3] THE SCRUM FRAMEWORK TRAINING BOOK BY INTERNATIONAL SCRUM INSTITUTE™，第65頁