Scrum估算會議

會議目的
  要做好戰略規劃，你需要知道 Backlog 中各項的大小，這是版本規劃的必要輸入；如果想知道團隊在一個 Sprint 中能夠完成多少工作，這個數據也是必須的。
  團隊成員可以從會議中知道項目接下來的階段會發生哪些事情。
 
基本要求
  只有團隊才能作估算，Product Owner（產品負責人）需要在場，以幫助判定某些用戶故事能否拆分爲更小的故事。
 
構成部分：
  Product Owner 根據業務價值排定 Product Backlog 各項順序。
  需要參加的人員：Team、Product Owner、User、Scrum Master
 
注意事項：
  不要估算工作量大小——只有團隊能這麼做。
  Product Owner 不參與估算。
 
會議過程
  Prodcut Owner 展示她希望得到估算的 Product Backlog 條目。
  團隊使用規劃撲克來估算 Backlog 條目。
  如果某個 Backlog 條目過大，需要放到下一個或是後續的 Sprint 中，團隊就會將該大 Backlog 條目劃分爲較小的幾個 Backlog 條目，並對新的 Backlog 條目使用規劃撲克進行估算。
  重新估算 Backlog 中當前沒有完成、但是可能會在接下來三個 Sprint 中要完成的條目。
 
持續時間：該會議時間限制爲不超過90分鐘。如果 Sprint 持續時間長於一週，那麼每個 Sprint 舉行兩次估算會議比較合適。
 
會議輸出
  經過估算的 Product Backlog。
  更小的 Backlog 條目。
 

撲克牌估算

具體步驟：
  每個人各自估算後獨立出暗牌，聽口令一起開牌。
  數值最大者與最小者PK，其他人旁聽也可參考。
  討論結束後重新出牌和開牌。
  重複上述過程，直到結果比較接近。
 
常見問題
 1、爲什麼任務要分給組而不是個人？
      因爲怕出錯了牌又說不出所以然，這樣即使日後他不做這個功能，也對這個功能很瞭解。
 
2、爲什麼不讓最後領任務的人自己估算？
      因爲他很可能因爲不知道某代碼可用、不知道某軟件不行....而選擇了錯誤的實現方法。
 
3、爲什麼不讓師傅估算大家採納，他不是最厲害嗎？
      師傅的想法常常是徒弟們理解不了的，比如爲什麼不留在女兒國而偏偏去西天取經之類的，共同估算就是讓大家在思考中對照自己的實現方法和師傅差異的過程。