但是在敏捷項目中，如何進行故事點的估算呢？

在軟件開發過程中，我們可能經常聽到老板和客戶問我們需要多少時間來完成項目？或者到某一個時間點，產品能做到什么程度？在瀑布模式下，項目經理們基本會給出明確的項目上線時間。

但是在敏捷項目中，特別是Scrum開發框架下，項目團隊變成了一個自組織團隊，沒有了“經理”，那我們如何開展這項工作？如何進行故事點的估算呢？

在Scrum的開發框架下，團隊共擔責任，集體承諾每個Sprint的工作，因此對于工作量的估算通過集體估算的方式進行。集體估算通常采用估算撲克作為工具。

估算撲克是基于共識的，游戲化的估算方法。估算撲克是寬帶德爾菲法的一種變體，由一組類似斐波納契數列的數字組成，這些數字包括：0，0.5，1，2，3，5，8，20，40，?，∞。它最常用于敏捷軟件開發，特別是Scrum和極限編程。那么如何采用估算撲克進行估算呢？

分牌

在估算會議上，team中的每位人員都會得到一副紙質撲克，當然，隨著移動互聯網的普及，目前大多數敏捷團隊使用了更為便捷的電子撲克。無論電子撲克，還是紙質撲克，牌上都需要包括這些數字1/2,1，2，3，5，8，13，20，40, ∞。

講解用戶故事

產品負責人按照排定的優先級順序從Product Backlog中選擇一個用戶故事，為大家詳細講解該用戶故事；team針對該用戶故事進行討論并提出問題，產品負責人逐一解答大家的問題。

當團隊成員確認已經對該用戶故事完全了解、無任何重大問題后，大家開始對該用戶故事進行估算。

估算時，首先，選擇一個比較小的用戶故事，確定其故事點，并將該故事作為基準故事。然后再將其他用戶故事和基準故事進行比較，得出其他用戶故事的相對點數，評估完成后，進行下一個用戶故事點數的評估。

估算點數差距比較大的處理辦法

如果估算值差距明顯，代表大家對該用戶故事的大小沒有獲得共識，高估計和低估計的人需要給出他們評估的理由。如在某一個用戶故事的評估中，有的人評估的故事點數為3，有的人評估的故事點數為13，有的人評估的故事點數為8，則評估故事點數為3和13的人需要說明評估理由，大家對該故事所包含的任務達成共識后，在對故事點數進行重新評估，直至大家對故事點數的評估基本達成一致。

如果對于同一個用戶故事的評估中，可能評估的故事點數不完全一致，但點數之間差距不大，比如在3和5個故事點之間，該用戶故事評估故事點數可以采用平均值法進行計算，將平均值結果與評估的故事點數比較，并把與評估故事點差值較小的故事點數作為用戶故事的最終點數。

如在A故事點的評估中，共有7人參與評估，其中4人評估的故事點數為3,3人評估的故事點數為5，則取平均值后的故事點數為3.85，與評估的故事點3和5比較，平均值與故事點3差值更小，所以，該用戶故事的最終點數為3，該用戶故事點數評估完成。

相關的問題

在哪一個會議上進行用戶故事點評估？

故事點評估一般在沖刺計劃會時進行，并需要選定主持人，主持人一般由Scrum Master擔任。

為什么需要產品負責人講解用戶故事？

講解用戶故事的步驟是team和產品負責人之間的交互的環節，能夠幫助team和產品負責人共同加深對用戶故事的理解。同時產品負責人也會根據大家的反饋，進一步完善用戶故事。

根據我的經驗，在講解用戶故事的過程中，千萬不要指定該用戶故事的負責人或明顯的傾向于某些人來做這個用戶故事，因為一旦指定了負責人員，可能會大大降低不負責該用戶故事的team其他成員的積極性，甚至會擾亂估算的秩序與結果。

估算完成后，可以任意亮牌嗎？

估算時每個人選出代表自己估算值牌面上的數字，每個人都將牌面朝下，不可立即亮牌，待team所有人員示意完成評估后，參與估算的所有人員同時亮牌。在估算過程中，團隊成員之間不可以互相商討。

這樣做是為了避免影響其他參與者，如果說出一個數字，它可能聽起來像一個建議，并影響其他參與者的評估。這一過程也是逐步提升team獨立思考的能力的一種手段。

估算與人/天，人/時有關系嗎？

估算的是一個相對值，而不是絕對值。和人／天，人／時沒有關系。假設我們以開車從北京到保定的工作量為參考基準，是1個故事點，那么從北京到太原的距離大概是從北京到保定的3倍，那么我們可以估算從北京到太原的工作量為3個故事點。

估算時，需要找一個參照物進行估算嗎？

每次估算時，最好使用相同的標準用戶故事，這樣對于整個項目的統計有很大幫助。使用相對值進行估算，可以有效的監控團隊的生產能力。

對于初次實施敏捷的團隊，對故事點的評估可能還是不太容易理解，根據我的實踐經驗，初次實施評估故事點時，可以嘗試1人/天的工作量作為一個故事點（與文中描述的“故事點和人／天，人／時沒有關系”這句話并不矛盾）。

產品負責人和Scrum Master參與估算嗎？

關于參與估算的人員范圍，team中的所有人員都要參與估算，可能的角色包括開發人員、測試人員，但不包括產品負責人和Scrum Master。這也是為什么建議team人數5-9人的原因之一，人數太少，會使估算結果偏差很大，人數太多，會拉長估算時間，降低估算效率。

評估時最大點數不超過多少合適？

取決于團隊。我們團隊確定的用戶故事最大點數為13，超過13，會將故事卡片進行進一步的拆分。

實際開發中發現了估算失誤要不要修改點數？

不必。估算是為了輔助我們的工作安排，而不是用來管理員工的績效表現。為了達到精準的估算而耗費了過多的時間盒精力，這是本末倒置。

有的故事卡片會比預計的先完成，有的會耗時更長一些，這些經驗的積累都會為團隊的下一次估算奠定更好的基礎。所以，單純地修改點數是沒有意義的。畢竟快速迭代就是方便我們試錯、改善。但如果做著做著發現故事卡中有深坑，建議再開一張卡片來填坑，這是比較常見的做法。

作者： 張洪強? ，微信公眾號：PMO雜談

本文由 @PMO雜談 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Pexels，基于CC0協議