彼此上篇文章說完了計劃會議，我們今天來一起探討一下計劃會議裡面一個很重要的環節，那就是故事點的估計。

故事點這個概念大家應該很瞭解了，實際上就是對在sprint裡面要開發的user story進行一個粗量級的估算，以便於團隊能夠知道這個user story的複雜度（工作量），但是這裡有個容易引起混淆的地方，就是傳統意義上的敏捷，是用來度量規模和複雜度。使用‘規模’和‘複雜度’這兩個詞，是要表達‘用完成任務所需時間來表示難度’。

從上面可以看出，由於故事點事對於規模和複雜度的估算，所以，首先他是一個不精確的值，第二，它應該是一個相對的值，由此來看，故事點是一個粗略的相對估算而不是精確估算。

那麼故事點的估算目的是什麼呢

作為PO來講，他在梳理ＰＢＩ和ＳＢ的時候，可能是想知道團隊多久能交付產品，每個迭代能夠交付多少使用者故事，所以故事點可以解決ＰＯ的這個困惑。我們可以通過估算故事點，然後統計多個迭代團隊交付的故事點數，然後相對的得到一個團隊的交付能力，比如說每個迭代交付２０個點的使用者故事，那麼如果PO有一個由100點的使用者故事組成的產品，那麼可以得知5個迭代完成這個任務。

也可以得到團隊的交付速率和交付能力的歷史資料，用來進行團隊回顧的資料依據。

在估算的過程中，因為所有團隊成員都要參與，大家對於故事的理解不一樣會造成估算的不同，這樣就需要PO和團隊成員之間進行需求的澄清，也是一個分析使用者故事需求和澄清的過程，能夠讓大家更好的理解使用者故事。

故事點估算的到底是工作量還是複雜度

在現實開發環境中，大家往往會有一個理解上的難點，到底故事點估計的是工作量還是複雜度呢？
從PO角度來講，肯定需要得到的是工作量，這樣也能第一時間知道產品開發的進度還有風險，但是如果估計的是工作量的話，那麼要和實際開發的人有關係的，因為同樣一個特性，對於熟練工和新手的工作量是完全不同的。

如果只是作為複雜度來估計的話，那麼產生的問題是：產品開發的複雜度在不同團隊和不同人員之間也是不一樣的，而且在現實開發環境中，對於複雜度的操作很難進行，有的時候大家會覺得費時費力。

從我個人來講，在敏捷不斷演進的過程中，現在故事點實際上是一個綜合的對於使用者故事的複雜度，規模，甚至還要加上承諾時間的一個度量了。也就是說團隊可以不必過度糾結在使用者故事的度量上，而是重點放在當前迭代裡能否按照該使用者故事的接收條件和團隊定義的ＤｏＤ來完成這個使用者故事，如果不能完成，給出理由，由ＰＯ來決定是否拆分或者重新設計使用者故事。這樣帶來的一個問題可能是ＰＯ在梳理ＰＢＩ的時候無法得知整個產品的全部完成時間，因為團隊的歷史交付資料可能不是一個穩定的速率（每個ｓｐｒｉｎｔ交付的點數差別會比較大，因為更注重使用者故事本身和交付承諾）

怎樣更好的運用故事點估計在計劃會議中

可以分為幾種情況：
1. 如果是新的一個團隊，那麼建議針對使用者故事進行估點，這樣一個能夠使得團隊儘快的熟悉起來，澄清需求，建立很好的溝通機制。
2. 如果是一個很成熟的團隊，對於產品比較熟悉，那麼這個時候故事點估計就不是十分必要了，因為大家都很熟悉產品特性，所以對於所需的工作量也是相對準確的，這個時候可能就需要團隊給出工作量的估計，讓ＰＯ對於產品的開發更好的進行進度和風險控制。
3.如果可能的話，針對不同的使用者故事型別設計不同的基準故事點，比如說開發的故事基準和測試的故事基準，實際上的工作量和複雜度是完全不一樣的。