? ? ? 看到有的團隊在Grooming會議怜奖、迭代計劃會議上對Story估算了點數(shù)以后，到了后期發(fā)現(xiàn)點數(shù)當時估算的不準確翅阵，于是就來問了：之前這個story是5個點歪玲，結果做到現(xiàn)在了迁央，我們發(fā)現(xiàn)它根本不是5個點的工作，應該是13個點滥崩，我們是不是要把這個Story的點數(shù)更新一下岖圈？
? ? ? ? 嗯，這個請求看起來合情合理钙皮。同意嗎蜂科？還是不同意？到底是修改呢還是不修改短条？
? ? ? ? 這其實就回到了敏捷的出發(fā)點导匣，為什么敏捷要不斷得做計劃（迭代計劃會議），為什么要經(jīng)常檢視計劃調(diào)整計劃（每日站會）茸时，根本的原因在于敏捷承認贡定，基于軟件開發(fā)的易變性、不確定性可都、復雜性厕氨、模糊性，任何事先的計劃都是不準確的汹粤。所以需要不斷得漸進明細去更新計劃命斧，使得之后的計劃能夠越來越接近準確。
? ? ? ? 所以當團隊在啟動迭代時對于迭代內(nèi)的Story的估算（故事點）代表了團隊當時基于對所有信息的了解而形成的對于需求的理解程度嘱兼。事后來看国葬，它代表了團隊在當時的計劃能力或水平。我們希望團隊在信息不完整的情況下能夠給出一個比較靠譜的計劃芹壕，這實際上是需要團隊具備的計劃估算能力汇四。
? ? ? ? 那么怎么衡量團隊計劃能力的高低，其實就拿團隊在迭代完成的故事點數(shù)與承諾的故事點數(shù)的比值就可以得到團隊做計劃的靠譜程度踢涌。希望這個比例在90%-110%之間通孽，說明團隊能夠比較好地應對這樣的不確定性。
? ? ? ? 比如還拿一開始的例子來說：一個初始估計是5個點的故事睁壁，實際做的時候發(fā)現(xiàn)相當于13個點故事的工作量背苦，有兩種情況。一種是這個故事在當前迭代還是完成了潘明，那么團隊也知道了這樣故事的復雜度行剂，下次碰到了類似的故事就自然會估的更準確些。但是這個迭代只完成了團隊一開始認為的5個點的故事钳降。另一種情況是團隊在當前迭代沒有做完厚宰，那么這個迭代沒有能夠創(chuàng)造這5個點的價值，知道在后面的迭代中完成這個故事遂填，才能在那個迭代掙到這5個點铲觉。而經(jīng)過這么辛苦的努力才掙到5個點澈蝙，那么下一次，團隊在估算時也會更努力的估算準一些撵幽。
? ? ? ? 而反過來碉克，如果團隊隨時調(diào)整故事的點數(shù)，雖然是數(shù)據(jù)準確的并齐，但是不能反映出團隊在做計劃時的估算能力漏麦。而且每次迭代完成時，所有的更新后點數(shù)都會是準確的况褪。這樣撕贞，團隊就失去的改進的動力，估算不準后面調(diào)唄测垛，這樣的計劃會議就會失去意義捏膨，不能變得越來越準，不能起到有效指導團隊工作的目的食侮。團隊的估算能力也不能快速提高号涯。
? ? ? 而JIRA背后的產(chǎn)品經(jīng)理，深知這個道理锯七。于是在形成迭代報告和Velocity報告的時候链快，Story的點數(shù)總是迭代開始時第一次估算的點數(shù)，后面再怎么修改點數(shù)也是不會反映到這兩個報告里去的眉尸。
? ? ? 大家可以試驗下域蜗，再好好想想是不是這個道理。
