故事點

故事點更多體現的是用戶情景或者bug的規模，采用斐波拉契數列(1,2,3,5,8,13)這樣的數字表示，包含如下內容：

1. 相對工作量
2. 復雜度
3. 風險和不確定性

相對工作量

下面演示一個Case來說明：
假設有個編輯頁面A有10個字段,B有100個字段：

B的相對工作量應該是較大但是不是絕對的10 倍。可能3-5倍。反應的就是故事點增加

如果考慮到已有的動態表單生成，那麽A和B兩個case應該是復雜度一致,反應的是故事點一致。

復雜度

對於上面100個字段這個case，如果字段中有一些數據綁定，復雜控件等等，那麽必然帶來復雜度的上升，反應的也是故事點的增加。

風險和不確定性

對於新的技術調研分析等，例如最開始去調查一個第三方api。某個技術實現可行性分析可以轉化成工作量。

註意

1. 考慮到不同實現思路帶來的不同工作量估算差異，開發應該可以對故事點進行調整。
2. 就拿距離來說，對於絕對距離的估算往往沒有相對距離準確。
3. 故事點只做相對大致的估算即可，不要求十分精確，但是要有足夠說服力。

速度圖

速度圖在待辦事項列表右上角，隨著時間的推移，速度應該是顯示一個可靠的，可用於預測平均完成故事點的數量。為了發揮速度圖的效益，需要滿足以下要求：

1. 按照團隊來規劃叠代內容(不要在頂層團隊規劃)
2. 為團隊定義叠代(叠代的時間應盡量相同)
3. 為每個團隊選擇叠代計劃(應盡量多分配2-3個叠代)
4. 需求盡量獨立,不要有太多關聯性(需求不要嵌套需求)
5. 叠代結束以後要及時更新將待辦項關閉，如果未關閉放到積壓工作重新規劃

6. 復雜bug需要評估故事點和任務拆分(復雜性需要開發自己評估)

   因為叠代內默認是由一定時間修復叠代內bug的，如果時間足夠可以修復歷史bug，但是部分復雜Bug需要時間較長，建議當作需求一樣來估算

速度預測

在情景代辦事項列表中打開趨勢預測(推薦隱藏進行中的項目)即可打開預測工具。
可以根據速度圖合理設置速度預測的值，即可使用預測功能。

註意事項

1. 要求針對每個用戶故事和Bug設置故事點
2. 可以對用戶故事和任務進行排序來重新預測
3. 速度的預測只是一個相對的值並非一個絕對的估算(這部分參照叠代容量規劃)

作用

1. 對項目未來的進度進行大致的規劃
2. 對待辦事項進行規劃(排序和優先級)
3. 針對預測合理的分配團隊的資源

容量規劃

基於叠代速度預測是大致的一個判斷，容量規劃可以幫助我們做精確的計算。但是容量的規劃，根據團隊的情況實際可以調整，不應該提前太多，這部分可以可以由團隊在叠代開始之初在計劃會議上確定。
配置步驟:

1. 選中某一個叠代，打開容量選項卡
2. 選擇團隊人員(可以包含產品，開發，測試等)
3. 配置每天的工作量(註意可以配置不同的活動).
4. 配置團隊休息日(周末默認休息，可把開發封板以後的工作日當作休息日)
5. 一般可以復制上個叠代的規劃，按照需要稍作修改即可

右邊即可出現團隊的容量

任務拆分

有了容量規劃,叠代的大致規劃後，我們需要對詳細做什麽進行規劃，而叠代的具體工作是根據任務來劃分,使用故事點做大致預測，使用任務剩余工作做詳細劃分,原因如下:

1. 故事點只是一個相對的概念，比較模糊
2. 需求拆分的過程可以對某個需求或者bug做實現層面的設計
3. 需求的拆分包含設計過程可以對需求的缺陷做提前的預防
4. 任務更加詳細方便做更加精確的估算
5. 任務初始估計和剩余工作新建時候相等
6. 任務初始估計和剩余工作以小時未單位

需求或bug拆分的任務需要填寫初始估計和標題即可，可以根據需要填寫詳細的內容。默認是誰的需求誰來拆分，誰拆分的任務就是分配給誰的。註意事項:

1. 需求應該由測試拆除一個用例設計的任務，活動為用例設計
2. 復雜Bug應該拆分任務。活動為bug修復

經過上述拆分以後在右邊既可以顯示每個人員總體的時間和完成叠代內任務需要的時間。根據最終拆分的結果適當的進行需求的刪減。

燃盡圖

選中某個叠代以後,右上角圖形即為燃盡圖。
可用容量的直線(最高點叠代開始出可用的最大工作時間，最低點0)
理想趨勢(最高點剩余工作的最大值，最低點0)
剩余工作(每天剩余工作的折線圖)

如下參考資料學習燃盡圖:

1. https://docs.microsoft.com/zh-cn/vsts/work/scrum/sprint-burndown
2. http://www.methodsandtools.com/archive/scrumburndown.php

TFS看板的叠代規劃