從我學習 Scrum 開始，大部分看到 Sprint Planning 估計 Story Point 的方法是用 Planning Poker。
但實際導入的過程中，稍嫌用 Poker 有點麻煩，所以找了其他的估計方法。
推薦一種我個人比較喜歡的估計方式，雖然我不知道這個方法的名稱，姑且稱之為九宮格估計法。
前言
估點之前，PO (Product Owner) 要先產出 Product Backlog。
且 PO 要讓每個成員都了解 PBI (Product Backlog Item) 的需求。
步驟
1. 垂直欄位
首先在白板上畫出三個垂直欄位，分別寫上小、中、大，如下：
2. 分類PBI
請團隊成員將 PBI 歸類在小型、中型或大型欄位，可以用難度、複雜度、範疇等作為比較基準。任何團隊成員都能有意見，開方式的互相討論，任意移動 PBI 位置。 切記！是讓團隊成員決定 PBI 放在哪裡，PO 跟 SM (Scrum Master) 這種不實際做事的角色不要亂入干預決定。但差距太離譜的部分，可能是需求認知不清，PO 可能需要主動解釋一下。
在我個人經驗裡，將 PBI 分為三類應該不會花太多時間。結果大致如下：
3. 水平欄位
橫向切出三個水平欄位，分別寫上小、中、大，如下：
4. 再次分類PBI
請團隊成員從左邊垂直區的小型欄位開始歸類在小小、小中或小大；分完後，將焦點移到中間的垂直欄分類，最後是右邊的垂直欄分類。
強烈建議不要一開始就畫九宮格，混在一起分九類。這個過程是希望的是每一次將一群 PBI 比大小，比大小比分類簡單很多。結果大致如下：
5. 點數估計
依序從左邊上至下再往右邊上至下，詢問團隊成員各群的差異倍率。如果是第一次預估點數，我建議將小小定義為0.5。
點數基本上以費氏數列 (1, 2, 3, 5, 8, 13, 21, 34, 55, 89) 或 Planning Poker 常用的點數 (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100) 皆可。
範例：
- 小小跟小中比較，若難度相當，小中則為0.5；若難度大於小小，小中則為1
- 小中跟小大比較，若小中為1，比較後難度較高，小大則為2
- 小大跟中小比較，若小大為2，比較後難度相當，中小則為2
- 中小跟中中比較，若中小為2，比較後難度較高，中中則為3
- 中中跟中大比較，若中中為3，比較後難度相當，中大則為3
- 中大跟大小比較，若中大為3，比較後難度較高，大小則為5
- 大小跟大中比較，若大小為5，比較後難度相當，大中則為5
- 大中跟大大比較，若大中為5，比較後難度較高，大大則為8
結論
實際執行過程中，這是蠻有效率又簡單的估點方法，很容易上手。
我個人是非常推薦給剛開始導入Scrum的團隊。