在 Scrum 團隊運作中，估算故事 (Story / PBI) 是不太容易弄清的，很容易陷入各種想要計算帶來的負作用。
如果大家翻閱書籍，或曾參加過課程、看過相關文章，不難發現時下有幾種估計標的，例如：故事點 (Story point)、T-Shiart Size、用手指比、用動物體型來類比，講到此你大概可以依樣畫葫蘆，說不定還能拿色碼表、溫度計來估計一下 (?)。
很快的你注意到一個問題－－時間呢？人天呢？不是應該估時間才合理嗎？
要解答這個問題，得先回頭看看這「點數」與「估計」究竟是怎麼一回事。
我們究竟想拿故事點幹麻？
實其是你想幹麻就可以幹麻，僅是「合適」程度的差別… 但我們還是來做點學問，看看社群上是怎麼認知「故事點」的。
它們是工作量的單位，而非真實的時間。它們甚至不是估算時間－－它們是估算的工作量。故事點數與工作量之間也不一定是完美的線性關係。請記住這些是估算，所以精確性是做意放得很寬。這些數字是模糊、不明確、不精確的，與真實的時間沒有直接關係。
— — 《Clean Agile 無暇的程式碼 敏捷篇》 p.78故事點受很多因素的影響，如複雜度和實際大小。
— — 《Scrum精髓 敏捷轉型指南》p.149故事點是粗略的，也是原始的工作量與規模的相對度量。相對度量利用了「規模大小本身就是相對的」這個特點，所謂的大與小是依照參考點而定的，而非絕對值。
— — 《Scrum 敏捷產品管理》p.65A story point is a metric used in agile project management and development to estimate the difficulty of implementing a given user story, which is an abstract measure of effort required to implement it. In simple terms, a story point is a number that tells the team about the difficulty level of the story. Difficulty could be related to complexities, risks, and efforts involved.
— — What is Story Point in Agile? How to Estimate a User Story?故事点的本质是对复杂度的估计，而复杂度其实包含了两部分 — — 难度和工作量。
— — 敏捷估算用故事点还是人天？而“故事点”就是敏捷开发创造出来的用来表示开发任务工作量的单位
— — 深度解析：故事点估算看这一篇就够了
從上述的觀點可以歸納出，故事點會受到這些因素的影響：工作量*、複雜度、困難度、風險。
* 關於「工作量」這邊做些補充，有時一不小心可能會把工作量以「時間」的方式呈現，建議用中性的方式來表達工作量。例如：要異動 10 張資料表、要遷移 100 萬筆資料、要改動 30 個頁面、要整理 1 千筆語系資源，這些資訊可以幫助團隊看到規模，也避免過早將時間量化出來。
要理解故事點可以幫助我們什麼，還得結合「規劃撲克」這個方法。
撲克的點數修改自費式數列，通常你會看到 0、1、2、3、5、8、13、21、34、55、89、144、∞、？、Coffee 這樣的牌組。
團隊會在規劃會議上對一個故事 (一個 PBI) 進行估計，試圖從 Product Owner 的說明理解故事，以自己的經驗認知投以最相近的點數，團隊同時掀牌後，看看是否有點數上的落差，並討論之間的差異在哪。
透過這樣的過程，團隊可以
- 促進討論，透過點數之間帶出來的「差異」找到討論的契機，例如釐清為何對相同的故事，你的估計有 8 點，而我的估計僅有 2 點。
- 避免資深人員或意見領袖主導估計，反而漏看了細節。
- 全員參與，刺激發想，帶出澄清的機會。
- 強迫思考，增加未來相互支援的可能。
- ……
當團隊掀牌時，若有出現明顯落差，主持人就可以成員發言，在個過程會澄清過度樂觀或悲觀的情況，通常經過 2 ~ 3 輪的投票，就會產生共識。當團隊遲遲無法達成一致 (或趨近)，則建議主持人出面仲裁，除了幫助團隊收斂之外，也避免在這無聊的議題上糾結。這同時也反應出，為什麼撲克點數會以費式數列改編而來，而不是單純的流水數值 1, 2, 3, … n，就是要避免一些討價還價，執著細節的情況出現。
在我的經驗中，估計過程確實有助於發現新的問題，同時我們也可以觀察到，當團隊日漸熟悉時，更多的問題還會提早在 PO 介紹故事時被發現。
對我而言，故事點與規劃撲克是一種「打開對話」的工具。
而對於「故事點」本身而言，在我的經驗中，它具有這些能力：
- 作為團隊討論的參照點
- 鑑別東西的大小
- 估算速率*，衡量相同團隊產出
但是，在展開任何的應用前，還得請大家面對現實 — — 「估不準」，小心使用，讓我們繼續看。
* 關於「速率」一事，補充《Clean Agile 無暇的程式碼 敏捷篇》提到的觀點 (p.79)：速率並不是一個承諾，這個數字只是他們的最佳猜測。
縱使有「？」牌可以運用，但估計時仍會有成員想挑一個數字出來，這時候點數之間的浮動可能更大；我想的與你想的不一樣；我的標準與你的不一樣；我覺得很簡單，你覺得很難…
於是，我們可以帶出另一個千古難題 — — 「這樣的評估怎麼會準確呢？」
是的，這確實是不準確的。在《Clean Agile 無暇的程式碼 敏捷篇》一書有段精妙的說法 (p.63)：
最誠實的估算就是「我不知道」。但是這樣的估算並不完整。你或許不知道所有事物，但有些事是你一定知道的。所以我期望你能根據你知道的以及你不知道的來做估算。
而在《敏捷管理生存指南 — 下》，也有個總結 (p.024)：
總結一下敏捷中的估計：接受估不準，把需求分解到夠小，利用估計充分溝通交換資訊。
讓我們來看看「時間」，對於一個故事而言，要直接估算時間是困難的，其一原因是材料太少，至少還得往下拆解，並套用實作經驗來估計，才可能得到一個勉強準確的估計值。你可能也發現了，面對同一個議題，若不同的人來處理、用了不同的工具、不同的工法，對於耗用時間會有多大的差別，這也顯得以單以一個故事來看，就得出工作時間是多麼奇幻的事。
故事點 (或 T-Shirt Size) 本身帶有的抽象性，除了幫助團隊打開對話，也避免了討論時的不協調。正因為時間太直觀 (真的嗎?)，太習慣把時間作為一種評判標準，若在討論過程中描繪了時間，難免會進行比較。A 對於這個故事胸有成竹，這肯定是 3 小時就可以搞定了；B 對於故事沒有把握，估且喊個 10 小時吧，再來團隊該如何認知呢？如何找到一個有代表性的值來代表這個故事呢？對於 A 與 B 來說，取什麼值都怪怪的，難有共識。
換個角度看，既然當下無法準確估計，何必擠出一個有利害關係的時間呢？它既無法滿足團隊，也少有人信任，出現在時程表上更是讓人毛毛的。
這也是為什麼，將「時間估計」的行為延至拆解出任務後發生，並由明確的負責人(開發人員)進行估計，是比較建議的做法。如此較有機會得到貼近現實的估時，也避免先前期討論故事時馬上落入時間的爭討。
當故事點被賦予更多的職責時，它會開始顯得怪異，有幾個常見的情境，值得我們思考看看。
把 Story point 作為不同團隊的比較。每個團隊聚眾而來的點數僅屬於該團隊，不同團隊的標準是無法比較的。再往下看，點數所代表的故事，在不同團隊原則上是實做不同故事的，本質上亦是無法較。
把 Story point 轉換為時間。這是比較危險的用法，雖然說有點大數法則的風味在，在足夠多的資料下，或許我們可以發現 Story point 與時間的關係，從中找到規律，但足夠多是多少？小心使用！如同文章前述提及的，影響到實作時間的因素非常多，這樣的轉換對應可說是基於估計的估計。
小結
- Story point 與規劃撲克是討論過程中的一種工具，其他帶來的能力都是多的，請不要對它有過度的幻想。
- Story point 不準確，與時間不是線性關係。
