在scrum培訓中，經常有人問：故事點和時間怎麼對應？忘記了那本書上曾經有個大牛舉了個例子，把系統中最簡單的乙個功能時間作為故事基準點，比如乙個**登入功能，從開始到發布大概需要8小時也就是1個人天作為故事點。於是，在很多公司中預設以此為基準點。在之後的敏捷計畫會議上直接用時間進行估算，甚至乾脆把敏捷撲克中的乙個點作為乙個小時，反正自己知道這是個1：8的關係。
mike大叔，曾經就此專門撰文指出：故事點和小時之間不存在等價關係；
或許我們可說，點數是工作量、風險和不確定性的函式，sp＝f(e,r,u)。重要的是，點數是關於工作量的估算。風險、不確定性、複雜度、未知因素以及其他相關的事，僅當他們會影響工作量時才應被包含進去。如果某些事確實很複雜，但卻不會影響實現特性所花費的時間，那麼複雜性就不應該對估算產生影響－這才是故事點。原文參見鏈結（
在scrum中故事的作用有如下幾點：
1 引起團隊和po之間的討論，對於一些商業開發來說故事可以最為技術人員和客戶溝通的橋梁，自始至終他們可以使用互相理解的語言進行溝通
2 故事是敏捷角色和儀式之間的唯一串聯
3 故事能夠充分的展示價值
4 相對估算，由於大部分的po或者網際網路中的產品經理並非技術出生，因此很難根據故事來估計絕對規模，事實上即使是開發人員也很難估計準確，但在相對規模上卻可以估算的比較精確，至少可以估計。
例如以登入功能為1個故事點，那麼搜尋功能呢？po可能會計算頁面複雜度是登入的3倍工作量，搜尋演算法也比登入複雜可能是3倍工作量，那麼搜尋就是6個故事點，不管如何起碼po能有乙個基準。
在這一步中完全沒有使用的時間。
接下來如何使用故事點來替換時間做到專案的監控和計畫的調整呢？
在乙個sprint計畫會議上，絕大多數的團隊會把故事拆解為任務，而任務的估算使用的是時間，假如我們選定了20個故事點進行開發，之後把他們拆分為任務並且估計每個任務的時間，再然後sprint正常進行，每天燃盡圖會根據任務進行的情況來更新，偽敏捷的典型方式是燃燒事件或者人天，我甚至在某知名軟體裡面看到過燃燒小時的機制。時間和人天的燃燒並不能給專案提供任何幫助，在固定迭代人天和工時是固定的，這個迭代差3個人天和5個小時反映不出任何有用資訊，敏捷開發是以經驗為模型的，我們期望的是上個迭代能給下給迭代提供參考資訊，相反我們在上個迭代完成多少故事點（縱座標為故事點數）卻是可以作為參考的。乙個長期穩定的團隊的故事點一定是如下圖所示的，也就是說每個迭代能完成多少故事是可以推算的，基於這種方式我們能看到專案的終點大概在什麼地方。
到目前位置時間也沒有顯示想象中的巨大作用。
最後乙個問題，如果我沒有基準，那麼怎麼填滿第乙個迭代呢？不是還得依靠時間嗎？應對第乙個迭代一般有兩種方式，一是通過分解任務直到填滿第乙個迭代，這個時候確實會和時間產生關係，但下乙個迭代就會以該迭代的完成故事點進行任務規劃，從此與時間無關；第二種方式是選取較多的故事點，第二個迭代以第乙個迭代完成的故事點作為依據選擇故事，有人以歷史專案資料為基準進行選擇其實也是一樣的原理。
其實在整個的敏捷開發過程中，時間真的是無關緊要，所以請忘記時間，使用故事點吧，不僅計畫會更精確，而且更具有追溯性。
敏捷中的溝通與故事點
當我讀到 scrum敏捷軟體開發 關於專案經理的討論時，讓我產生了極大的共鳴，使我不得不放下書來閒扯兩句，一方面抒發自己的感受，另一方面也算是一種反思吧。我平時一般要同時帶3 5個專案。作為專案經理，我都要花上大部分時間去分析需求，然後將其拆分成小任務。拆分任務時，我會將任務錄入到我自己設計的專案管...
敏捷讀書之使用者故事 《使用者故事與敏捷方法》解讀
本期分享mike cohn 使用者故事與敏捷方法 精益思想五步 價值，價值流，流動，拉動，盡善盡美。使用者故事是精益思想五步的核心載體。首先，使用者故事是價值載體，是承載使用者價值的基本單元。使用者故事要承載價值，而價值也要承載在使用者故事這種歸一化的載體中。其次，使用者故事是節拍器。故事有節奏的流...
《使用者故事與敏捷方法》 Scrum
scrum是乙個迭代和遞增的過程。一輪迭代的過程是一種持續改進的過程 乙個遞增的過程是指按照功能點開發和發布軟體。每乙個功能點 功能增量 代表乙個完整的功能子集。每乙個功能增量都能被完整地實現以及測試通過。scrum和極限程式設計都是基於遞增和迭代方式的過程。這兩種過程都在一輪新的迭代開始之前為迭代...