上一次我們介紹了Scrum的背景，工具及大致流程（點選檢視）。本次我們對估點及燃盡圖進行詳細講解。

估點

具體操作為，先指定一個使用者故事作為基準點數(1點，半點，或2點，一般不建議超過2點)。其他任務，跟這個使用者故事作比較，進行評估。

為什麼不按時間來估？

很明顯，每個人能力不一樣，同一個事情，基本上所有人需要花費的時間都不一樣，難以統一； 而如果按相對難度來估，大部分情況下，應該都是差不多的，更容易統一。以下是估點的範圍值：

無窮大和問號，都可以表示太複雜，難以估計，這時需要拆分任務。

為什麼估點不是連續的？

這是為了減少估點難度，讓我們聚焦於難易度，而不是糾結在點數上。比如一個任務，發現它比另外一個3分的任務要難一點，但比5分的任務要簡單很多，則可以估為3分。EduSoho的做法是，超過5分的點，儘量拆分，讓大部分任務都更容易預估。

如何進行確定一個任務的點數？

官方的估點方式是，各個組員把點數定好，統一亮出（防止互相影響），再看結果，最大的和最小需要進行PK，各自闡明理由，再新來一輪，複雜的使用者故事往往會有很多輪（開發人員才會參與估點）。 估點是整個Scrum過程中執行起來最複雜，最費時的工具，5個人的小組，一週內容的迭代會中，估點要花2~4個小時。
EduSoho的做法是，最多2輪，第一輪亮出後，如果差別不大（只差一個級別），取投票最多的點數，相差如果很大，比如大部分為2，有一個是0.5，有一個是5，則由0.5和5分別說明，再投一輪，直接取第二輪中投票最多的點數。同時，Scrum Master事先和Project Owner討論需求，將使用者故事拆分，迭代計劃會議上就不用做拆分操作，從而節約大量時間。
估點可以量化團隊的交付能力。新團隊前面幾個迭代的估點非常不準，但估個3~4次，大家都有了共同的認識，每個迭代的估點就比較穩定，也就能知道團隊大概能交付多少個點。同時，如果開發人員分職級，可以按照職級來要求每個程式設計師需要做多少點，當團隊變動時，也可以根據變動人員的職級來調整團隊的交付能力。

燃盡圖

如上圖，剩餘故事點（估出來的點數，即故事點）的趨勢圖即為燃盡圖。理想狀態下，是一條線段，最後一天是0。通過畫燃盡圖，能讓大家一眼看出是否有進度風險。但實際上，可能會發生需求變更，導致中途點數反而變多了。EduSoho的做法是，固定迭代中的點數，當有新任務進來時，Scrum Master估點，然後和Project Owner協商，移除一部分點數的任務，保證總量大致不變。

EduSoho額外引入的環節

專案啟動會

一個專案啟動時，整個團隊會叫上相關的銷售，市場，運營，由Project Owner和Scrum Master介紹需求，給出專案截止日期，儀式感很重要。

專案演示

整個專案結束後，整個團隊面向整個公司做演示，並且提供直播，讓全部小夥伴瞭解相應業務，同時給整個小組帶來榮譽感。