了解story point的定義及用法之後，通常需要一段長時間會議，來設定專案所有卡片的story point。管理者最後會得到一個加總的數值，就是專案=XXX story point。那這個數值也什麼用處呢? 答案是，沒用。哈，你沒看錯，花了這麼大的功夫得到的數值，居然沒用，那你是在給我裝笑維哦。其實，是需要經過幾次的SPRINT之後，才會有用(所以管理者要多點耐心)。因為每次的SPRINT會安排工作，幾次之後，管理者就可以知道團隊1個SRPINT會完成多少點，也就可以知道最後的完成日。舉例來說，A專案總計story point=250，而團隊1個SPRINT為2週平均作完20個點，也就是完工日會在2週*(250/20)=25周的日期。
這裏就出現了一個很大的問題了，一般專案不是都有完成日期嗎? 如果SCRUM計算後的日期來不及在專案完成日交付，怎麼辦? 這時，有3個方式召集團隊來檢討，先後順序是
1是減少團隊障礙，讓團隊可以加速。例如受限於某主機採購時程過長，管理者要想辦法縮短採購時間，或先採取替代方案，讓團隊可以減少等待時間等等。
2是與客戶協商減少工作卡片或困難度(因為與story point有關)，因為直接刪除最不重要的卡片工作，或是降低工作困難度，減少story point。
3是增加資源，包含增加團隊人力或工作外包。通常這是最後的方法，但也是最不容易辦到的，因為資源是在專案開始就限制了，如果可以爭取到額外資源，當然是最好。
4是以上都檢討後，若仍無法於專案期限內完成，只能辦理契約展延或被處罰了。(沒救了…)
那我們團隊是如何作的呢? 數列的選擇我們是1,3,5,8,13(2感覺與1太近捨棄)，且我們是遠距工作，所以一起出數字比較有困難度，所以出點數時，卡片負責作的人最後出，由其他人先出數字(避免月暈效應)，如果數字差距過大，就要說明及重新計算story point，每SPRINT為一週，管理者每週SPRINT會議紀錄每個人完成點數，並安排次週工作。雖然大幅度減少月暈效應的產生，但日後還是要設計一個給遠距團隊投票的機制。