我对scrum和用户故事有一个快速的问题。
我正在为一所大学开展一个小项目，我决定使用Scrum和用户故事来解决这个问题，我知道Scrum通常是由一组团队成员完成的，但在我的情况下，我只是在做一个项目主管。
我理解用户故事以及指向和优先级系统的内容，例如（必须，应该，可能，不会）
现在，当我即将结束迭代时，让我们说大约有一半的用户故事已经完成。
我的用户故事的一个例子是：
“用户需要能够记录设备”
我为这个用户故事创建了很少的子任务，除了1个子任务之外，我已经达到了所有这些任务，并且我已经到了迭代的末尾。我给这个用户故事写了8点。
现在我不确定我是否可以将这个用户故事包含在燃尽图表中，或者我等到子任务完成后再添加到图表中。
我还想问一下，根据我在用户故事中完成的任务的基础，或者总是基于完整的用户故事包括测试等，我可以根据我的Burn Down图表。
提前致谢！
答案 0 :(得分：1)
一些提示：
燃尽图表示任何一天在冲刺中剩余的估计工作小时数，因此不包括冲刺外的任何内容。通常情况下，故事的估计点是团队成员（在本例中为您）对故事所附带的努力和风险的反映。当故事被分解为任务时，这些任务通常以小时计算 - 最佳实践是任务不应超过一天或直到下一个每日Scrum的时间。
我认为你问题中的一个基本问题可能是“我是否可以计算在短跑结束时我完成的故事部分？”。可悲的是，答案是“不”。使用Scrum的最佳方式是关于完成故事的非常黑白 - 它要么完全“完成”，要么完全“完成”。没有中间立场。对团队所做的工作取决于他们，只要它是在前面定义而不是移动目标。在我的情况下，如果QA成员作为裁判的“可交付质量”，我们会使用规则。
如果故事不可发送，无论是50％还是99％完成，它都会失败。没有部分功劳。如果发生这种情况，故事会以积分重新估计，重新放回积压状态，产品负责人有机会查看他/她是否想要为下一个冲刺重新选择它。这也是重新评估故事估计的好时机 - 对于一个正常规模的团队来说，8pt的故事很大，对于一个人来说，这个故事太大了。理想情况下，团队的目标故事大小应该在2-5左右。最后，如果你无法完成8pt的故事，那就是你的速度太高的信号，你需要在下一个冲刺中做更少的分数。