Ste*_*idt 8 scrum user-stories task burndowncharts
有几种方法可以在Scrum中烧掉图表.
有些人建议使用未完成的故事的故事点作为Scrum中的烧毁图表.
专业:只有完成的故事会降低图表
对比:图表在开始时不会向下移动,然后会迅速下降
其他人建议使用剩下的任务数量
Pro:图表将向下移动,您可以看到它是否在终点线之上
反对:你最后可以向下移动说10个任务(硬任务),但仍然没有完成一个故事.你失败了,因为只有完成的strories对你的产品所有者有好处.
解决方案是否同时包含未完成故事点和未完成任务图表？
我们正在使用剩余时间进行冲刺燃烧 - 团队每天都可以看到进展.如果有平坦的部分,那么它们确实发生过.
在发布日程中,我们使用的是故事点.发布计划更多的是关于他的功能完整性,时间是在冲刺级别跟踪.产品所有者对已完成的故事感兴趣.
任务数量无用.这个数字每天都可以更改,特别是如果你给开发人员一个"自由".他们可以在不改变总时间的情况下将任务拆分为较小的部分.这样的统计是没用的.它表明了什么？它会影响冲刺的目标吗？
我们两者都做，就好像我们不包括任务一样，我们的生产线将会陷入停滞状态，看起来就像什么都没完成一样。
如果一个故事需要 2 天才能完成，那么这 2 天的线路是平坦的，并且无法判断团队是否按兵不动，或者工作量增加了（因此任务时间有所增加）。
当然，任务线可能会直线下降，而不会有助于完成故事，如果开发人员可以随意选择任务，则可能会出现这种反模式。