在 <都說要估算，但怎麼估始終是個謎> 一文中我們提到在 Scrum 中為什麼要估算，以及使用相對估算的方式比較容易。但問題來了，實際估算點數的過程，實務上應該怎麼帶領呢？

規劃撲克

早在 2002 年，就有一位敏捷大前輩 James Grenning 設計出一種方式，規劃撲克（Planning Poker），透過這種近似遊戲的方式，讓夥伴們在估計工作項目時能夠達到群體共識。之所以命名為撲克，是因為他會用到一組牌卡，特別的是這組牌卡的數值是以費式數列所組成。

為什麼採用費氏數列

在 設計師背景的 PM 最討厭的 數學裡，費氏數列定義是：

由 0 和 1 開始，下一個數是由前兩個數相加而得出，例如 1、 2、 3、 5、 8、 13、 21…

一般直覺會認為，撲克應該會是 1, 2, 3, 4, … , 12, 13 點這般像傳統的撲克牌一樣的點數，但為何這套「規劃撲克」的點數非得要用獵奇的費氏數列呢？原因很簡單，因為人類並不擅長分辨絕對意義上的大小，問自己體感上感知的到 5 小時與 6 小時有什麼差別嗎（尤其是打遊戲時），如此就能體會了。

雖然不太能分辨出絕對大小，但出乎意料地，人類卻很擅長分辨相對大小，再加上若我們讓後面的大小差距愈來愈大，就更加能夠辨析出相對的量級。例如，你跟主管說做 A 這件事需要於休息日加班 3 小時，做 B 需要 4 小時，但你週六最多只能加班 5 小時，請求主管協助判斷做決擇，此時主管在體感上其實難以分辨 A 與 B 的復雜度差異；但若你說 A 需要 2 小時，B 需要 5 小時，那麼主管就能夠感知到 B 的復雜度高了 A 一個等級。正因如此，所以費氏數列的數字，相當適合拿來做為 Story Point 的單位。

如何開始

規劃撲克的估點活動開始時，引導者（通常是 Scrum Master），會發給團隊每一位成員一組費氏級數的牌卡。接著，依照以下的步驟：

1. Scrum Master 大聲唸出第一個用戶故事／任務項的內容
2. 大家在心中盤算，判定各自對於這個故事／工項的點數（至於 1 點是什麼意思，每個團隊、專案可能定義不同，只要大家基準相同即可。有需要請參考 <都說要估算，但怎麼估始終是個謎> 一文中的說明）
3. 團隊成員每個人各自決定好要出的點數並手持該張卡牌
4. 所有人同時翻開卡片
5. 如果大家的估算都相同，就直接填上點數，繼續進行下一個故事／工項的估算與出牌，重覆步驟 1-5
6. 若大家的估算不盡相同，那麼 Scrum Master 請這二位出的點數最低及最高的夥伴輪流發言，說明他們認為要出這麼小／這麼大點數的觀點。
7. Scrum Master 請所有成員重新再考慮 1 分鐘，然後重新出牌
8. 若這次點數估算都相同了，就直接填上點數，繼續進行下個故事／工項的估算與出牌，重覆步驟 1-5
9. 若這次還是不同，Scrum Master 詢問大家是否接受民主（少數服從多數），接受的話，繼續進行下一個項目的估算

上述步驟看起來好像很多，似乎也很花時間？有趣的是，實務上屢試不爽，經過至多二或三回合的出牌、觀點討論後，不同估算都會相當迅速地收斂靠攏。

要點總結

1. 故事點對於不同團隊有著不同的定義。所以故事點最好不要拿來作為評估團隊績效的標準（雖然實務上很難，Rson 就是每次在 Sprint Review 時，都被逼著要面對燃盡圖曲線不佳的焦慮折磨，然後被當作績效來評斷，話說明天就又要面對它了，快幫我 QQ）
2. 該故事有資格出牌的人，最好至少是會該實作技術的人（不信的話下次可試試看，讓設計師為後端工程師出點數，保証每個 API 都覺得這不難吧，給你 2 點應該就很佛心了唷 啾咪~）
3. 估點時若有不理解該項目的地方，記得提出請產品負責人回答
4. 故事點的標準一定要統一，比如說是「刻一個 log in / out 的前端頁面」為 1 點，其它是相對這個標準而定
5. 不見得一定要用實體牌卡（雖然比較有療癒感＋苦中作樂，搭配杯飲料好像在打牌更棒棒），沒有實體卡的話用手指或是線上的 Plan Poker 也非常方便