故事点

故事点更多体现的是用户情景或者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