故事點 是敏捷項目管理和開發中的一種抽象的度量單位，用於估計實現一個或多個用戶故事的復雜度，它是對工作量的一種描述方式。一個故事點就是一個數字，透過這個數字告訴整個團隊用戶故事的復雜度。復雜度包括功能的難易程度、風險和花多大的功夫。
故事點（story point）和預估時間（estimated）不一樣，故事點是一種相對的估計，它並不能和類似“人/天”這樣的單位畫等號，因為每個人完成同樣復雜度的工作所需的時間是不同的。我們舉個例子說明一下：
假設T團隊有A、B、C三位員工，A君的能力是B君的2倍，B君的能力是C君的2倍（能力是不能這樣對比的，這里只是方便說明問題），T團隊約定10天為一個迭代，現在他們想計划一下未來的工作。如果按照預估時間的方式，一個用戶故事B君覺得需要1天，A君覺得0.5天就可以，C君覺得需要2天，那么他們最終定多少呢？
這里可能出現兩種結果：
第一種結果，A君說這個我來做，寫0.5天吧！如果按照這個方式，那么整個計划會議就演變成分工會議，A君挑若干的用戶故事，自己進行估時，B君和C君也是如此，當每個人的總估時都逼近10天的時候，那么這個迭代的目標就確定了。這是很多團隊實際采用的方式，看起來好像沒問題，但是久而久之，這種方式的弊端就會顯現出來。
-
自己干自己的，不關心全局的進展。既然每個人自己的工作內容都已經確定，那每個人安排好自己的工作就可以了，何必關心別人的工作呢？
-
抗風險能力差。如果A君請假1天，需要C君花4天才能彌補。不僅對C君的計划影響巨大，也讓整個團隊的預估和實際相差甚遠。
-
看不到團隊的真實速率。每當PO詢問某些用戶故事能不能安排到下個迭代時，通常得到的答案是“這要看誰有沒有空”。
-
不利於團隊成員的成長。C君很難有機會做一些復雜的，對自己能力有提升的工作，因為出於時間成本的考慮，復雜的工作都交給A君來處理。
當然，還有第二種可能，大家決定取個中間值，可是中間值定多少才算合理呢？預估的時間多就意味着整體完成的工作量變少，預估的時間少意味着完不成的概率會增大。
不同於預估時間，故事點關注的是復雜度，讓所有人對同一個用戶故事有相同的復雜度認知。為了做到這一點，T團隊可以找到一個基准的用戶故事（下文稱為基准故事），基准故事不一定是最小的，但是一定能在T團隊中每個人心中引起共鳴，然后T團隊將第一個基准故事定義為1個故事點。
在估算一個新的用戶故事X時，所有人都需要思考，故事X比基准故事更花時間嗎？如果故事X的復雜度是基准故事的2倍，那么很顯然，故事X的故事點應該為2。需要注意的是，故事點的取值要遵循斐波那契數列（1、2、3、5、8、13、21、34… ），不過為了方便記憶，在實際的操作中，很多團隊將21替換20，34替換成40等等。下圖是我的Scrum撲克牌。
這些紙牌表示的意思是：
-
0表示喝口水的時間就能完成。
-
其他數字是根據和基准故事對比得出的結論。
-
?表示復雜度未知，通常需要對用戶故事進行討論或者拆分。
-
咖啡表示估算的太久，有點累了，需要休息一下。
原則上，一個好的敏捷團隊，不應該為超過8個故事點的用戶故事估算，大於等於8個故事點的用戶故事應該被拆分為更小的用戶故事。而隨着時間的推移，T團隊中會出現越來越多的基准故事，這些基准故事對應的故事點可能是1，也可能是2，也可能是3。這使得所有人對於新用戶故事的估算越來越准確。
當然在實際的工作中，由於每個人實際情況的不同，即使所有人都明白1個故事點意味着什么，依然會為一個用戶故事的故事點是2還是5而產生爭論。有的人考慮的多，有的人考慮的少，有的知道一些近路，有的人一臉茫然。正確的步驟是這樣的：
-
所有人先不要說出自己的故事點，而是將對應的紙盤扣在桌子上。
-
當所有人的紙牌都扣在桌子上時，大家一起翻開自己的卡牌。
-
請估算差異最大的兩位成員討論，各自估算的原因。
-
所有人收回紙牌，重復步驟1-4。直到所有人的估算一致為止。
使用這種方式的好處是顯而易見的，它能讓所有人對這個故事點有一個共識，這意味着，不管誰來完成這個用戶故事，那么他是認可這個故事點的。而且它可以有效的避免不假思索的跟風行為，每個人必須對用戶故事的復雜度進行思考，才能給出一個相對可靠的故事點，否則就要向所有人進行解釋。
使用這種方式也有它的弊端，那就是計划會議非常耗時。在實踐中，有的團隊將估算的環節放在計划會議之前，而有的團隊不借助撲克牌，而是直接通過全員討論得出一個相對正確的故事點。
T團隊對於用戶故事的估算是需要不斷的磨合的，同時還有一個需要不斷磨合的是團隊速度。A君B君C君已經在計划會議中為若干個用戶故事完成了估算，總故事點約為40，那么T團隊能夠完成這個40個故事點嗎？實踐是檢驗猜測的唯一方式。
隨着幾個迭代的嘗試，T團隊發現30個故事點的工作量剛剛好，不緊也不慢，那么T團隊的團隊速度即為30個故事點/10天。
團隊速度的作用之一是，如果T團隊在一個迭代中規划了總計為30個故事點的用戶故事，不管每個用戶故事是A君B君C君誰來做，理論上這些用戶故事T團隊都能按時完成。當然T團隊的速度不是一成不變的，下圖是我所在的團隊最近三個迭代的團隊速度。
（截圖來自Worktile Agile）
根據過去一段時間的團隊速度來規划下一個迭代的工作規模，是非常科學的。
T團隊對自己團隊的能力有着清晰的認識，也對迭代的目標充滿着信心。另外，T團隊還可以根據自己的團隊速度，在迭代中插入一定比例的非功能性需求。
除了團隊速度，使用故事點也可以非常直觀的體現T團隊在一個迭代中的工作進展，下圖是我所在的團隊Sprint 10的燃盡圖。
（截圖來自Worktile Agile）
燃盡圖的趨勢可以有效的體現T團隊目前是否失控，如果燃盡圖總是居高不下，所有人需要在站立會議中進行討論，共同發現、承擔並解決問題，這才能稱得上是一個團隊，不是嗎？
本文作者：Worktile 孫敬雲
Worktile 官網：worktile.com
文章首發於「Worktile官方博客」，轉載請注明出處。